Obscure .eh_frame debug info question.

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Horsley wrote:
> I was just wondering if there is anyone out there in redhat
> land who can shed more light on the use of dwarf register 16
> for a virtual "return address" in .eh_frame info, probably
> hand generated .eh_frame info in the vicinity of the
> pthreads library mutex locking code.

This has nothing to do with hand-generated or not.  The debug and
exception handling information has to contain information on how to find
the return address at any point in the program.  In Dwarf this is best
done by expressing the return address as a register, even if it is not a
register on real hardware.  r16 is that register for x86 and the DWARF
info describes how to find it.


> The .eh_frame dumps of the pthread library via readelf
> make no sense to me at all.

Then nothing I explain will make any sense.  You'll have to understand
how DWARF allows to describe a "program" to recover register content etc.

For r16 it starts usually with

     offset r16 (rip) at cfa-8

Which means the value is at offset -8 from the call frame register.
This is defined as well in the same block.  In short, this points at the
beginning of the function to the most recently pushed value on the
stack.  Later modifications of the stack pointer have to be accompanied
by appropriate adjustments of the CFA and therefore the return address
can always be found.

It is possibly to load the return address into a register.  At that
point the unwind program would contain an entry like

   cfi_register rip rax

or so.

It's really all pretty simple, just read the DWARF specification.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoVgHAACgkQ2ijCOnn/RHTOqwCeJMVhICvwbeSLRsbgxfs3vQAU
1/YAoKJnO/UI5MAvR914zK+JB/zYIiAE
=GCFq
-----END PGP SIGNATURE-----