[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
You might find this useful:
- 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 
>> > 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
>> o Can users safely trim .eh_frame from her/his kernel?
> Yes, but it should not be the default behavior...
Main Index |
Thread Index |