Re: .eh_frame

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

You might find this useful:

http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-October/005546.html

Several notes:

- while eh_frame is meant to be the minimum information needed to
unwind function calls, the desire to unwind through C code and signals
from C++ means that most systems ship with the same detailed
information as found in .debug_frame

- assembler is often augmented with hand written eh-frame code so that
the unwinder's life is made easier (I should check but I suspect that
it doesn't duplicate the info to debug-frame so stripping it out will
make a debuggers life hard)

So, does your kernel contain C++ code using exceptions, hand written
eh-frame code, or an in kernel consumer? :-)
Another useful data point might be to post the numbers, how much space
does it take up?

PS: If it isn't a GNU extension (as in first implemented in GCC), I'd
love to know what it is.



On 9 November 2014 17:12, Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> On Mon, Nov 10, 2014 at 01:40:59AM +0900, Masao Uebayashi wrote:
>> On Mon, Nov 10, 2014 at 1:24 AM, Joerg Sonnenberger
>> <joerg%britannica.bec.de@localhost> wrote:
>> > On Sun, Nov 09, 2014 at 09:26:45PM +0900, Masao Uebayashi wrote:
>> >> o .eh_frame is GNU extension debug info to unwind stack [1]
>> >
>> > No.
>>
>> Ian Lance Taylor said that it is similar to DWARF .debug_frame, but different.
>
> Yes, but it is not a GNU extension.
>
>> >> o .eh_frame in kernel is not used yet, and safely removed from /netbsd
>> >
>> > Please do not.
>>
>> o Is it correct that .eh_frame is not used by anything at all at the moment?
>
> gdb should in principle, haven't tried. libunwind is not hooked into ddb
> (yet).
>
>> o Can users safely trim .eh_frame from her/his kernel?
>
> Yes, but it should not be the default behavior...
>
> Joerg