From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8832A3858288; Wed, 15 Feb 2023 10:22:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8832A3858288 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676456525; bh=AW8JqUyVMDiQF+dXs+QQA5DY0PCIQNq/+JGfOic4RwM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bHx+fbdxEBYxcn5qbQnB02ehrqPskFKpmsYXVZ5lP1b50iXjw0+zlj4AHYQhUOmZA aUTG8GQ9ScHkjHYFwoowKY7DIcA8p/mvFDTQaIenDuVlQOlFwXRwYe208uAdtI4z4l 2vogtWBPkV6QSHWQ71aY2ZRUisBpd/Nx1ZrgKT2Y= From: "corinna at vinschen dot de" To: gdb-prs@sourceware.org Subject: [Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable Date: Wed, 15 Feb 2023 10:22:03 +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: In-Reply-To: References: 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: https://sourceware.org/bugzilla/show_bug.cgi?id=3D18027 --- Comment #12 from Corinna Vinschen --- (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. >=20 > 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 somewher= e? 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=20 > > used to reconstruct the originl address? >=20 > binutils has a workaround based on _bfd_dwarf2_find_symbol_bias > (see bfd/dwarf2.c). >=20 > 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) =3D> 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. >=20 > One idea I had is to assume that some function lives in the first text pa= ge > 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=