tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: .eh_frame

You might find this useful:

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 <> 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
>> <> 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

Home | Main Index | Thread Index | Old Index