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 <ja...@redhat.com> 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. > > > 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... > > Jakub >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
