Dear all > I am still confused though, can we check this example together?
Sorry for the noise, I made a silly mistake and the addresses in the hexdump, which are off by 0x10. Problem solved, thank you for the help! -francesco > 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 <ccout...@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 >> > >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
