[Dwarf-Discuss] doubt parsing CIE in eh_frame

[Francesco Zappa Nardelli]

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 <jakub at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160524/ba0e45a0/attachment.htm>