Re: DWARF references crossing shared library boundaries

[todd dot allen at ccur dot com (Todd Allen)]

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

   Right on both counts.  We never even considered your first idea, and we
   rejected the second one because we simply cannot force users to pay the
   extra time for debug relocations most often programs aren't being
   debugged.

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

   Right again.  Our debugger actually does map in all the dwarf up front,
   since we can do it for cheap with mmap().  Even so, it holds the
   relocations on the side until it needs them, just because it doesn't want
   to pay the time cost of doing any relocations that it doesn't have to.

-- 
Todd Allen
Concurrent Computer Corporation