Dear David and all If you could produce a small object file..
Invoking readelf on /lib/x86_64-linux-gnu/libc.so.6 is enough to observe this (I am on Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-68-generic x86_64)): $ readelf -wf /lib/x86_64-linux-gnu/libc.so.6 (and search for S in the augmentation string) 00002690 0000000000000014 00000000 CIE Version: 1 Augmentation: "zRS" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop while readelf -wF gives: 00002690 0000000000000014 00000000 CIE "zRS" cf=1 df=-8 ra=16 LOC CFA 0000000000000000 rax+0 Remark: objdump emits the same output. I believe that this is the unwinding information for the longjmp call, and the unwinding infos are computed from a structure on the stack representing the processor state to which we want longjmp: 000026a8 000000000000007c 0000001c FDE cie=00002690 pc=0000000000036d3f..0000000000036d49 LOC CFA rax rdx rcx rbx rsi rdi rbp rsp r8 r9 r10 r11 r12 r13 r14 r15 ra 0000000000036d3f exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp 000026a8 000000000000007c 0000001c FDE cie=00002690 pc=0000000000036d3f..0000000000036d49 DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 160; DW_OP_deref) DW_CFA_expression: r8 (r8) (DW_OP_breg7 (rsp): 40) DW_CFA_expression: r9 (r9) (DW_OP_breg7 (rsp): 48) … (and so on for all registers)… So it makes sense to ignore whatever in the CIE here. I am just surprised that readelf/objdump prints “rax+0”: I would have expected “u” as the CFA in the CIE is never computed by the CIE bytecode. Wonder if I am missing something... -francesco On Tue, May 24, 2016 at 1:34 AM, David Anderson <dave...@linuxmail.org> wrote: > On 05/23/2016 02:10 PM, Francesco Zappa Nardelli wrote: > > Dear DWARF-discuss > > > > I am writing a parser of eh-frame informations and I have a doubt about > > a behaviour of readelf. > > > > On a (statically linked) binary readelf reports the following eh-frame > > CIE entry: > > > > 00006f38 0000000000000014 00000000 CIE > > Version: 1 > > Augmentation: "zRS" > > Code alignment factor: 1 > > Data alignment factor: -8 > > Return address column: 16 > > Augmentation data: 1b > > > > DW_CFA_nop > > DW_CFA_nop > > DW_CFA_nop > > DW_CFA_nop > > DW_CFA_nop > > DW_CFA_nop > > > > and readelf interprets this bytecode as: > > > > 00006f38 0000000000000014 00000000 CIE "zRS" cf=1 df=-8 ra=16 > > LOC CFA > > 0000000000000000 rax+0 > > > > My doubt is: where does the rax+0 come from? Is rax some kind of a > > Register names are not specified by the DWARF std. > Nor are the DWARF numbers that identify registers. > Implementations turn the DWARF register numbers (ABI specified) into > strings (names specified by the ABI).. > > Note that .eh_frame is a GNU invention so not formally part of DWARF > at all. Though .eh_frame is mostly identical to .debug_frame. > > Hope this makes sense. Does not answer your question (sorry). > > If you could produce a small object file which > has the above and that can be made public > I would love to have it in my libdwarf regression test suite :-) > Email it (or the location of the file > on the web) to libdwarf-list 'at' linuxmail =dot= org > David Anderson > _______________________________________________ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
