[Dwarf-Discuss] doubt parsing CIE in eh_frame

[Francesco Zappa Nardelli]

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