[Dwarf-Discuss] _starting address_ in eh_frame FDE encoding

Francesco Zappa Nardelli francesco.zappa.nardelli at gmail.com
Tue Mar 29 09:01:32 PDT 2016


Cary, thanks for your reply!  I am still confused though, can we check this
example together?

Here is an annotated hexdump for the first CIE and FDE of an eh_frame table:

$ hexdump -C -s 0x580 -n 658 foo2
00000580  14 00 00 00 00 00 00 00  01 7a 52 00 01 78 10 01
          length    | ID        |  v  aug    | af df rr la

00000590  1b 0c 07 08 90 01 07 10  14 00 00 00 1c 00 00 00
          *| opcds  .     .     || length    | ptr to CIE|
*FDE encoding (aug = R) : 1b = PC_REL, sdata4

000005a0  00 fe ff ff 2a 00 00 00  00 00 00 00 00 00 00 00
          strt_addr*|                                   ||

The CIE augmentation data state states:

  DW_EH_PE_pcrel, DW_EH_PE_sdata4

The untranslated starting address in the FDE (noted strt_addr) is

  fffffe00 (that is -200 in hex, -512 in dec)

which, according to readelf must be translated to

  pc=00000000004003a0

The offset since the beginning of the eh_frame of the strt_addr field is
32, and

 $ readelf -S foo2
There are 34 section headers, starting at offset 0xc20:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
...
  [16] .eh_frame         PROGBITS         0000000000400590  00000590
       0000000000000114  0000000000000000   A       0     0     8

In hex,  400590 + 20 = 4005b0, is this the “PC address” that we should
consider when we parse the PCREL start address?  If yes, 4005b0 - 200 =
4003b0, but we should have got 4003a0.  Can you point me to where I am
wrong?

Thank you again.

Best
-francesco



On Thu, Mar 24, 2016 at 3:47 PM, Cary Coutant <ccoutant at gmail.com> wrote:

> > I have a question about the FDE encoding in eh_frame (and not
> dwarf_frame)
> > tables.
> >
> > This document (I could not find a better description of eh_frame)
> >
> >   http://www.airs.com/blog/archives/460
>
> The official description of the .eh_frame section, with a description
> of the augmentation string and what the various DW_EH_PE values mean,
> can be found in the relevant psABI document for your architecture.
>
> > states that:
> >
> >   "An FDE starts with the length and ID described above, and then
> continues
> > as follows.   1 The _starting address_ to which this FDE applies. This is
> > encoded using the FDE encoding specified by the associated CIE.”
> >
> > In a sample elf file, the associated CIE augmentation data state reports:
> >
> >    DW_EH_PE_pcrel, DW_EH_PE_sdata4
> >
> > and the untranslated starting address value in the FDE is fffffe88
> > (according to readelf this should be translated to 4004d0).  I do not
> > understand what “value is PC relative” means here, as we are actually
> > defining the range of PC values.
> >
> > Can somebody explain me how to interpret this _starting address_ field?
>
> PC-relative simply means that the value is not an absolute address,
> but rather an offset relative to itself (i.e., the address of the
> field that contains the value. The value you read there was
> 0xfffffe88, which, according to the augmentation string, is a signed
> 4-byte value, or -0x178. If you add that to the address of the
> starting address field itself, you'll get the actual starting address,
> which readelf has computed as 0x4004d0. Working backwards, that
> implies that your FDE started at 400640, with the starting address
> field at 0x400648.
>
> -cary
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160329/75166f6a/attachment.htm>


More information about the Dwarf-Discuss mailing list