[Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable

["corinna at vinschen dot de" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18027

--- Comment #12 from Corinna Vinschen <corinna at vinschen dot de> ---
(In reply to Tom Tromey from comment #11)
> (In reply to Corinna Vinschen from comment #10)
> [...]
> > In fact, the first question is probably if the dwarf2 info couldn't
> > by imagebase-relative, rather than absolute.  If that's possible
> > (and maybe even already handled in GDB?) this could be done by tweaking
> > the linker.
> 
> I think this would be better, but won't it cause issues if we then
> use gdb to debug existing executables?  Since those will have the
> offsets already in the DWARF?

Isn't there some kind of version information in the DWARF sections somewhere?
GDB could use that to distinguish absolute vs. load-address relative DWARF
info.

> > ...then it would be great if GDB could workaround this somehow.
> > The problem here is, I have no clue if there's anything in the DLL
> > which would be indicative of the original image base address after
> > rebasing.  Unless, maybe, some of the dwarf2 info itself can be 
> > used to reconstruct the originl address?
> 
> binutils has a workaround based on _bfd_dwarf2_find_symbol_bias
> (see bfd/dwarf2.c).
> 
> What this does is look for a function in the DWARF that has an address,
> then tries to find that same function in the linker symbols.  When
> it finds a match, it uses those addresses to compute the delta.

Yeah, that actually sounds very simple:

  load address in header: 0x300000000
  func foo in .text: 0x300021300
  func foo in DWARF: 0x4d9241300

  --> original load address at the time the file was created:
  0x300000000 + (0x4d9241300 - 0x300021300) => 0x4D9220000

> This could work in gdb as well, it's just very unfortunate to have to do it.
> However it's hard to see another way.
> 
> One idea I had is to assume that some function lives in the first text page
> and try to use the lowest address seen (this is easier to get just from
> scanning
> the DWARF) to compute the offset, but this fails for cases like a DLL with
> a mix of -g / no-g objects.

We have to assume that the DLL has been built with debugging symbols.  SO
we can safely assume that the DllMain function is always present.

As symbol to look for, one could use DllMain for DLLs, and WinMainCRTStartup
otherwise, they are always present in Cygwin executables.

Alternatively, we know exactly where the .text section starts in a Windows
executable.  .text is at load address + 0x1000.  And there's always *some*
symbol at this address.  So it would be possible to figure out that symbol,
fetch it from DWARF and use the above offset computation, no?


Corinna

-- 
You are receiving this mail because:
You are on the CC list for the bug.