From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 8B1F63858C83; Fri, 21 Apr 2023 19:48:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B1F63858C83
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1682106481;
	bh=P++rXwJiJ6bPlnU+VPEh9BO45RIoWs3PQ04Dj2ufcCo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=cNiTEbeH8t2hFcItuY+FjeNgba+/gxh53M9naE0dCd5PDwFGQfnqFx7u72ZLwEvCI
	 BVoHmGKr1NoPDUTJ2xc6q6Cr3fnAEYsImUVwAbC0yCBua6fCFGEwVM6gUDFJ8+Mnwk
	 IzgTIicGZ0p9O78b90HsAuTmpIFJilhJieRNowN4=
From: "corinna at vinschen dot de" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable
Date: Fri, 21 Apr 2023 19:48:01 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: win32
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: corinna at vinschen dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-18027-4717-IgWplFpCJN@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-18027-4717@http.sourceware.org/bugzilla/>
References: <bug-18027-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

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

--- 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:
>=20
> Idx Name          Size      VMA               LMA               File off=
=20
> Algn
>   0 .text         00000648  0000000300001000  0000000300001000  00000600=
=20
> 2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>=20
> 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:
>=20
> (top-gdb) print/x pe_rebase_offset(abfd)
> $12 =3D 0x300001000
>=20
> 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 =3D (IMAGE_DOS_HEADER *) ADDR;
  IMAGE_NT_HEADERS64 *nt_hdr =3D (BYTE *) dos_hdr + dos-hdr->e_lfanew;
  ULONGLONG image_base =3D nt_hdr->OptionalHeader.ImageBase;

The orginal, pre-rebase image_base value is a 32 or 64 bit value in the new=
ly
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

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