Re: [Dwarf-Discuss] doubt parsing CIE in eh_frame
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) 2690 0014 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: 2690 0014 CIE "zRS" cf=1 df=-8 ra=16 LOC CFA 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: 26a8 007c 001c FDE cie=2690 pc=00036d3f..00036d49 LOC CFA rax rdx rcx rbx rsi rdi rbp rsp r8r9 r10 r11 r12 r13 r14 r15 ra 00036d3f exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp exp 26a8 007c 001c FDE cie=2690 pc=00036d3f..00036d49 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 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: > > > > 6f38 0014 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: > > > > 6f38 0014 CIE "zRS" cf=1 df=-8 ra=16 > > LOC CFA > > 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
Re: [Dwarf-Discuss] doubt parsing CIE in eh_frame
On Tue, May 24, 2016 at 09:46:58AM +0200, Francesco Zappa Nardelli wrote: > 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) The only zRS I see in my libc.so.6 is the __restore_rt trampoline in sigaction.c. https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sigaction.c;h=71ac05c4bc01c560935f3bbd4306e3aeacb6d9be;hb=HEAD The CIE doesn't contain any (non-nop) instructions, so guess readelf -wF's default for no instructions at all is the first register. Does it really matter? The (only) FDE that refers to this CIE defines the CFA expression as the very first thing in it, so it isn't really ever used. Though, perhaps you might want to file a request to move the do_cfa_expr macro into the CIE from the FDE - I think DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 160; DW_OP_deref) is 6 bytes and therefore would fit exactly into the padding at the end of the CIE. > 2690 0014 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: > > 2690 0014 CIE "zRS" cf=1 df=-8 ra=16 >LOC CFA > 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: > > 26a8 007c 001c FDE cie=2690 > pc=00036d3f..00036d49 >LOC CFA > rax rdx rcx rbx rsi rdi rbp rsp r8r9 > r10 r11 r12 r13 r14 r15 ra > 00036d3f exp > exp exp exp exp exp exp exp exp exp exp exp > exp exp exp exp exp > exp > > 26a8 007c 001c FDE cie=2690 > pc=00036d3f..00036d49 > 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... Jakub ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] doubt parsing CIE in eh_frame
Dear Jakub The only zRS I see in my libc.so.6 is the __restore_rt trampoline in sigaction.c. https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sigaction.c;h=71ac05c4bc01c560935f3bbd4306e3aeacb6d9be;hb=HEAD The CIE doesn't contain any (non-nop) instructions, so guess readelf -wF's default for no instructions at all is the first register. Does it really matter? I do agree that it does not matter, I was just surprised by the readelf behaviour and I wanted to be sure I was not missing something important. Thank you all for the help, problem solved. Though, perhaps you might want to file a request to move the do_cfa_expr macro into the CIE from the FDE - I think DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 160; DW_OP_deref) is 6 bytes and therefore would fit exactly into the padding at the end of the CIE. Ah, clever! -francesco On Tue, May 24, 2016 at 10:07 AM, Jakub Jelinek wrote: > On Tue, May 24, 2016 at 09:46:58AM +0200, Francesco Zappa Nardelli wrote: > > 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) > > The only zRS I see in my libc.so.6 is the __restore_rt trampoline in > sigaction.c. > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sigaction.c;h=71ac05c4bc01c560935f3bbd4306e3aeacb6d9be;hb=HEAD > > The CIE doesn't contain any (non-nop) instructions, so guess readelf -wF's > default for no instructions at all is the first register. Does it really > matter? The (only) FDE that refers to this CIE defines the CFA expression > as the very first thing in it, so it isn't really ever used. > > Though, perhaps you might want to file a request to move the do_cfa_expr > macro into the CIE from the FDE - I think > DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 160; DW_OP_deref) > is 6 bytes and therefore would fit exactly into the padding at the end of > the CIE. > > > 2690 0014 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: > > > > 2690 0014 CIE "zRS" cf=1 df=-8 ra=16 > >LOC CFA > > 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: > > > > 26a8 007c 001c FDE cie=2690 > > pc=00036d3f..00036d49 > >LOC CFA > > rax rdx rcx rbx rsi rdi rbp rsp r8r9 > > r10 r11 r12 r13 r14 r15 ra > > 00036d3f exp > > exp exp exp exp exp exp exp exp exp exp exp > > exp exp exp exp exp > > exp > > > > 26a8 007c 001c FDE cie=2690 > > pc=00036d3f..00036d49 > > 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... > > Jakub > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] doubt parsing CIE in eh_frame
On 05/24/2016 12:46 AM, Francesco Zappa Nardelli wrote: >> 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) > > 2690 0014 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: > > 2690 0014 CIE "zRS" cf=1 df=-8 ra=16 >LOC CFA > rax+0 rax is the x86_64 64bit reg . As a 32bit x86 reg it is named eax. IMO this is an accidental side effect of the way dwarf.c is implemented in binutils. If printing eh_frame it won't print the CFA_nop but finishes up with a print of the resulting cfa reg which never got set so is zero. Zero results in printing rax+0. So I think this is just a simple bug in readelf. David Anderson ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] doubt parsing CIE in eh_frame
On 05/24/2016 01:07 AM, Jakub Jelinek wrote:
> On Tue, May 24, 2016 at 09:46:58AM +0200, Francesco Zappa Nardelli wrote:
>> 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)
The bug in readelf (I think) is at the end of display_debug_frames() in
dwarf.c (binutils directory).
The frame_display_row call is a bit odd if all that exist are nops and
results in the rax output
we see.
===
if (do_debug_frames_interp)
frame_display_row (fc, &need_col_headers, &max_regs);
start = block_end;
eh_addr_size = saved_eh_addr_size;
}
printf ("\n");
return 1;
}
DavidA.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
