This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: DWARF references crossing shared library boundaries
- To: David B Anderson <davea at quasar dot engr dot sgi dot com>
- Subject: Re: DWARF references crossing shared library boundaries
- From: Michael Eager <eager at eagercon dot com>
- Date: Sat, 03 Mar 2001 13:33:57 -0800
- CC: Todd Allen <todd dot allen at ccur dot com>, dwarf2 <dwarf2 at corp dot sgi dot com>
- References: <200103010125.SAA61908@toad.ccur.com> <200103012105.NAA18534@quasar.engr.sgi.com>
- Reply-To: Michael Eager <eager at eagercon dot com>
David B Anderson wrote:
>
> If the debug info is left on disk at run time, not
> mapped in at all, then it's up to the debugger
> to deal with the relocations. It will have to find them
> and resolve them with ABI-dependent techniques.
> But the 'addresses which are relocated'
> have to be in memory so effectively the debugger must
> hold the relocations on the side till they can be applied
> (unless one assumes the entire dwarf is mapped into debugger memory early
> and relocated then).
The standard doesn't prescribe how one processes Dwarf data, and, in
many cases, we've said that the internal representation need not and
perhaps should not correspond to Dwarf.
That said, the debugger can read the Dwarf data and the relocation
information at the same time, applying relocations as needed, without
loading the Dwarf data into memory. Or it can map the Dwarf data into
memory and apply all of the relocations at one time. Or there may
be other ways.
> Up till now I suspect most of us
> simply assumed that the dwarf itself was unchanged by anything
> done at run time (ie, unchanged by the fact things are
> not assigned virtual addresses till app runtime).
One of our goals has been to reduce the number of relocation in
the debugging data. In the case of Dwarf in one shared library which
does not have references to symbols in other shared libraries, all
references would be relative to the current shared library. A relocation
is needed, but it is based on the address where the library is loaded.
Clearly, once you open the door to references from Dwarf in one
shared library to symbols in another shared library, you implicitly
require a debugger to not only relocate Dwarf entries relative
to the current shared library, but also to handle other relocations.
This requirement holds, even if you never have this situation.
--
Michael Eager Eager Consulting eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077