On 05/09/2017, 12:00 PM, h...@zytor.com wrote: > As far as I understand, the .eh_frame section is supposed to contain the > subset of the DWARF bytecode needed to do a stack unwind when an exception is > thrown, whereas the .debug* sections contain the full DWARF data a debugger > might want. Thus .eh_frame is mapped into the runtime process while .debug* > [usually?] is not. .debug* can easily be 10x larger than the executable text > segments.
As it currently stands, the (same) data is generated either to .eh_frame, or to .debug_frame. Depending if DWARF_UNWINDER is turned on, or off, respectively. vdso has the same data in both, always. > Assembly language routines become problematic no matter what you do unless > you restrict the way the assembly can be written. Experience has shown us > that hand-maintaining annotations in assembly code is doomed to failure, and > in many cases it isn't even clear to even experienced programmers how to do > it. Sure, manual annotations of assembly will be avoided as much as possible. We have to rely objtool to generate them in most cases. > [H.J.: is the .cfi_* operations set even documented anywhere in a way that > non-compiler-writers can comprehend it?] Until now, I always looked into as manual: $ pinfo --node='CFI directives' as > I'm, ahem, highly skeptical to creating our own unwinding data format unless > there is *documented, supported, and tested* way to force the compiler to > *automatically* fall back to frame pointers any time there may be complexity > involved, I second this. Inventing a new format like this mostly ends up with using the standard one after several iterations. One cannot think of all the consequences and needs while proposing a new one. The memory footprint is ~2M for average vmlinux. And people who need to access: * either need it frequently -- those do not need performance (LOCKDEP, KASAN, or other debug builds) * or are in the middle of WARNING, BUG, crash, panic or such and this is not that often... And we would need *both*. The limited proprietary one in some sort of .kernel_eh_frame, and DWARF cfis in .debug_frame for tools like crash, gdb and so on. And yes, the DWARF unwinder falls back to FP if they are available (see function dw_fp_fallback). thanks, -- js suse labs
