Re: DWARF references crossing shared library boundaries

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

Todd Allen
> The biggest extension that we've made to DWARF 2.0.0 is to permit DWARF
> DW_FORM_ref_addr references to reference debugging information entries in
> another shared object.


> This deviates from the text in 7.5.4 discussing references of form
> DW_FORM_ref_addr, where it says "within the same executable or shared
> object".  I'd like to loosen up that language.

Michael Eager
>My first impression is that a shared library which contained a DW_FORM_ref_addr
>which was not resolved would have a relocation table entry.  A debugger can
>resolve this reference when it reads the Dwarf data, since it generally
>has information about all of the shared libraries which are loaded.

>I don't see a problem with permitting DW_FORM_ref_addr to be unresolved
>in a shared library.

Hmm. Thinking aloud about this:

If a linker puts dwarf info into the program image (read only)
then at runtime one is in trouble: the read-only data is not
alterable.

If the linker puts dwarf in read-write space any linking at run-time
costs time (and most apps don't use the debugger at all).


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).

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).

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/