From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2111) id 20AC53858CD1; Wed, 6 Dec 2023 20:14:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20AC53858CD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1701893656; bh=zsdA8Ct1I2fQi5FbPQPMjX92e/EZZiqbA/iG2ddEfc8=; h=From:To:Subject:Date:From; b=KMaG4nnPE6OgTJrLk60dTRlooAo/fekDL0LfHvrBVnx4vi4/L5fHXoSU1PY3Hful4 s6nS+iHAFESK9iTdTHKU4uhamX53qJeMDi1AVRxZBq8MmwVP4/iCgQcTPkKQvr9Z6k L74Fg2cyWGUDf/gtaxJWI84FdJk4lhrPXG//3vfI= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Hannes Domani To: gdb-cvs@sourceware.org Subject: [binutils-gdb/gdb-14-branch] Fix DLL export forwarding X-Act-Checkin: binutils-gdb X-Git-Author: Hannes Domani X-Git-Refname: refs/heads/gdb-14-branch X-Git-Oldrev: f04aac2ba4e3135748c8833a5ef26e5b9a85fd66 X-Git-Newrev: 43a608adb04251be8999304cf724f55b2d840ac3 Message-Id: <20231206201416.20AC53858CD1@sourceware.org> Date: Wed, 6 Dec 2023 20:14:16 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D43a608adb042= 51be8999304cf724f55b2d840ac3 commit 43a608adb04251be8999304cf724f55b2d840ac3 Author: Hannes Domani Date: Wed Dec 6 20:52:06 2023 +0100 Fix DLL export forwarding =20 I noticed it when I was trying to set a breakpoint at ExitProcess: ``` (gdb) b ExitProcess Breakpoint 1 at 0x14001fdd0 (gdb) r Starting program: C:\qiewer\heob\heob64.exe Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x3dbf4120 Cannot insert breakpoint 1. Cannot access memory at address 0x77644120 ``` =20 The problem doesn't exist in gdb 13.2, and the difference can easily be seen when printing ExitProcess. gdb 14.1: ``` (gdb) p ExitProcess $1 =3D {} 0x77644120 ``` gdb 13.2: ``` (gdb) p ExitProcess $1 =3D {} 0x77734120 ``` =20 The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a, where VMA was then calculated relative to FORWARD_DLL_NAME, while it was relative to DLL_NAME before. =20 Fixed by calculating VMA relative to DLL_NAME again. =20 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31112 Approved-By: Tom Tromey =20 (cherry picked from commit 2574cd903dd84e7081506e24c2e232ecda11a736) Diff: --- gdb/coff-pe-read.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gdb/coff-pe-read.c b/gdb/coff-pe-read.c index 56137ac4dd0..8e30c6a4a61 100644 --- a/gdb/coff-pe-read.c +++ b/gdb/coff-pe-read.c @@ -210,7 +210,10 @@ add_pe_forwarded_sym (minimal_symbol_reader &reader, " \"%s\" in dll \"%s\", pointing to \"%s\"\n"), sym_name, dll_name, forward_qualified_name.c_str ()); =20 - unrelocated_addr vma =3D msymbol.minsym->unrelocated_address (); + /* Calculate VMA as if it were relative to DLL_NAME/OBJFILE, even though + it actually points inside another dll (FORWARD_DLL_NAME). */ + unrelocated_addr vma =3D unrelocated_addr (msymbol.value_address () + - objfile->text_section_offset ()); msymtype =3D msymbol.minsym->type (); section =3D msymbol.minsym->section_index ();