building kernel with -O

Xin Tong trent.tong at gmail.com
Wed Jul 30 21:05:25 EDT 2014


In that case, the __builtin_return_address(level) level > 1 is not possible
either ? what if the kernel uses this ?

Xin


On Wed, Jul 30, 2014 at 8:00 PM, Peter Teoh <htmldeveloper at gmail.com> wrote:

>
>
>
> On Thu, Jul 31, 2014 at 12:59 AM, Xin Tong <trent.tong at gmail.com> wrote:
>
>> why can not __builtin_return_address() be made *never* inline and use
>> current level+1 to get the return address of the function of interest.  For
>> any stack introspection, having 1 more level will not hurt functionality.
>>
>
> Actually, the answer for your remark is "impossible" - in the case when
> the kernel is compiled without frame pointer.   (CONFIG_FRAME_POINTER=n)
> which is true for certain variant of RHEL / CentOS.   Without the
> availability of EBP on the stack, there is no way to know when to stop
> reading the stack to retrieve the previous stackframe.   Of course u can
> statically walk the disassembly of the function and see how much stack
> space the particular function has allocated.   But that requires
> implementing a disassembler in the kernel.
>
>
>
>>
>> given its explanation below
>>
>> — Built-in Function: void * *__builtin_return_address* (unsigned int
>> level)
>>
>> This function returns the return address of the current function, or of
>> one of its callers. The level argument is number of frames to scan up
>> the call stack. A value of 0 yields the return address of the current
>> function, a value of 1 yields the return address of the caller of the
>> current function, and so forth. When inlining the expected behavior is that
>> the function returns the address of the function that is returned to. To
>> work around this behavior use the noinline function attribute.
>>
>>
>>
>>
>
> --
> Regards,
> Peter Teoh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140730/15902cba/attachment.html 


More information about the Kernelnewbies mailing list