.eh_frame
Do I understand this correctly? o .eh_frame is GNU extension debug info to unwind stack [1] o .eh_frame is generated by GCC/LLVM [2] o Some code under src/sys/ reference it, but not finished & hooked to any kernel functionality (ddb(4)?) o .eh_frame in kernel is not used yet, and safely removed from /netbsd [1] http://www.airs.com/blog/archives/460 [2] http://nxr.netbsd.org/search?q=DW_EH_PE_absptr&project=src [3] http://nxr.netbsd.org/search?q=DW_EH_PE_absptr&project=src&path=%2Fsrc%2Fsys%2F
Re: .eh_frame
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. > o .eh_frame is generated by GCC/LLVM [2] Yes. > o Some code under src/sys/ reference it, but not finished & hooked to any > kernel functionality (ddb(4)?) Yes. > o .eh_frame in kernel is not used yet, and safely removed from /netbsd Please do not. Joerg
Re: .eh_frame
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. >> o .eh_frame is generated by GCC/LLVM [2] > > Yes. > >> o Some code under src/sys/ reference it, but not finished & hooked to any >> kernel functionality (ddb(4)?) > > Yes. > >> 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? o Can users safely trim .eh_frame from her/his kernel?
Re: .eh_frame
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
Re: .eh_frame
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 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
Re: .eh_frame
On Mon, Nov 10, 2014 at 4:02 AM, Andrew Cagney wrote: > 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? :-) According to joerg@, there is nothing (yet). > Another useful data point might be to post the numbers, how much space > does it take up? My XEN3_DOMU (amd64) kernel has: [ 1] .text PROGBITS 8010 0010 003a57a8 AX 0 0 64 [ 2] .eh_frame PROGBITS 804a57a8 004a57a8 0007ccb0 A 0 0 8 [ 3] .data PROGBITS 80622480 00622480 000281c0 0000 WA 0 0 64 (.rodata is merged into .text.) .eh_frame is 500K, which is not negligible. > PS: If it isn't a GNU extension (as in first implemented in GCC), I'd > love to know what it is. joerg@ should know. :)
Re: .eh_frame
On Mon, Nov 10, 2014 at 2:12 AM, 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). Good to see these are clarified, finally. >> o Can users safely trim .eh_frame from her/his kernel? > > Yes, but it should not be the default behavior... If users find 500K is wasted and complain that, what is your answer?
Re: .eh_frame
On 9 November 2014 17:12, Joerg Sonnenberger wrote: >> >> 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). Can you be more specific? A remote debugger will call on either .debug_frame or .eh_frame when generating a back-trace - what it uses depends on what it chooses to look for first at each address. In fact, ignoring the potential for bugs, you could: - strip .eh_frame - strip all debug info except .debug_frame and still have good back-traces without weighing down the kernel's text segment with .eh_frame info. Andrew
Re: .eh_frame
On Mon, Nov 10, 2014 at 06:06:54PM +, Andrew Cagney wrote: > On 9 November 2014 17:12, Joerg Sonnenberger wrote: > >> >> 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). > > Can you be more specific? > > A remote debugger will call on either .debug_frame or .eh_frame when > generating a back-trace - what it uses depends on what it chooses to > look for first at each address. In fact, ignoring the potential for > bugs, you could: > - strip .eh_frame > - strip all debug info except .debug_frame > and still have good back-traces without weighing down the kernel's > text segment with .eh_frame info. Consider x86_64 where you can't do reliable stack unwinding without also disabling -fomit-frame-pointer. The question is not about .debug_frame vs .eh_frame, you don't get the former at all without explicitly asking for debug data. Joerg
Re: .eh_frame
On 10 November 2014 18:21, Joerg Sonnenberger wrote: > Consider x86_64 where you can't do reliable stack unwinding without also > disabling -fomit-frame-pointer. The question is not about .debug_frame > vs .eh_frame, you don't get the former at all without explicitly asking > for debug data. You've lost me. I agree that without the help of CFI (call frame information), amd64's stack is impenetrable goop. That just means that we need to ensure that there is cfi information on hand should someone need it - in the .debug_frame section instead of .eh_frame. (small technical nit, currently to get just the .debug_frame section, gcc seems to require: -fno-unwind-tables -fno-asynchronous-unwind-tables -g; which seems a tad excessive given that gas's .cfi_sections pretty much does all we need) As an aside, even with no CFI, it's still possible to get a feel for what went down - just scan the stack for what look like code addresses.
Re: .eh_frame
On 10 November 2014 06:53, Masao Uebayashi wrote: > >> So, does your kernel contain C++ code using exceptions, hand written >> eh-frame code, or an in kernel consumer? :-) > > According to joerg@, there is nothing (yet). BTW, looks like arm (sys/arch/arm/include/profile.h) may contain hand-written eh-frame code. That shouldn't be a problem as, from gas: 7.11 `.cfi_sections SECTION_LIST' = `.cfi_sections' may be used to specify whether CFI directives should emit `.eh_frame' section and/or `.debug_frame' section. If SECTION_LIST is `.eh_frame', `.eh_frame' is emitted, if SECTION_LIST is `.debug_frame', `.debug_frame' is emitted. To emit both use `.eh_frame, .debug_frame'. The default if this directive is not used is `.cfi_sections .eh_frame'. it is easy to change. It's just a shame that more ports aren't exploiting this feature. Makes unwinding less debugger-tool centric.
