On Mon, Nov 10, 2014 at 4:02 AM, Andrew Cagney <andrew.cag...@gmail.com> 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 ffffffff80100000 00100000
00000000003a57a8 0000000000000000 AX 0 0 64
[ 2] .eh_frame PROGBITS ffffffff804a57a8 004a57a8
000000000007ccb0 0000000000000000 A 0 0 8
[ 3] .data PROGBITS ffffffff80622480 00622480
00000000000281c0 0000000000000000 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. :)
