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

corinna at vinschen dot de sourceware-bugzilla@sourceware.org
Fri Apr 21 19:48:01 GMT 2023


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

--- Comment #29 from Corinna Vinschen <corinna at vinschen dot de> ---
(In reply to Tom Tromey from comment #27)
> Another oddity is that the .text section says:
> 
> Idx Name          Size      VMA               LMA               File off 
> Algn
>   0 .text         00000648  0000000300001000  0000000300001000  00000600 
> 2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
> 
> The VMA is offset by 0x1000.

No, the VMA is correct.  Please keep in mind that the PE/COFF file has a
leading 4K block, the file header.  The file header is loaded into the
address space together with all other sections.  ImageBase is the address
of the PE/COFF file header, NOT the address of the .text section.

> So my function to compute the offset also says that:
> 
> (top-gdb) print/x pe_rebase_offset(abfd)
> $12 = 0x300001000
> 
> Does this matter?  I don't know... but each section has a different offset
> here, so if it does matter, then we'd have to know which section each
> DWARF entity comes from.

Using the .text address is wrong.  The address where the image gets loaded to
is in the PE header header and the entry is called image_base.  It should
be available via bfd, shouldn't it?
If not, assuming you map the file into memory at address ADDR, then you can
use Windows definitions to access ImageBase (example for x86_64):

  IMAGE_DOS_HEADER *dos_hdr = (IMAGE_DOS_HEADER *) ADDR;
  IMAGE_NT_HEADERS64 *nt_hdr = (BYTE *) dos_hdr + dos-hdr->e_lfanew;
  ULONGLONG image_base = nt_hdr->OptionalHeader.ImageBase;

The orginal, pre-rebase image_base value is a 32 or 64 bit value in the newly
defined .debug_pe_defaddr section.

So the offset is just the difference between the above current image_base
from the file header and the value stored in the .debug_pe_defaddr


HTH,
Corinna

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


More information about the Gdb-prs mailing list