Re: .eh_frame

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Mon, Nov 10, 2014 at 4:02 AM, Andrew Cagney <andrew.cagney%gmail.com@localhost> 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. :)