From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 08F603858C62; Mon, 13 Feb 2023 22:08:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08F603858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676326107; bh=w2zqyzVYxlIQJFkzdQjLQcbobLmMSbLKQwV/in8YwYM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yM2vitpWskErwIspGInTLjVLp+sdMGD32vaIUjX8v/wMMkMgWl14C6mZRNbHYlBEQ pAsHu8/ZTFkgsKxzDcWVx/fMQKT5h2mjASSum7fbSgMHyeWVecnWcb8QZ7eZJUkd9r j74AmZy8YlPQc9/b0sbaYx60OTAeJXrbw0D/Bpgs= From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable Date: Mon, 13 Feb 2023 22:08:26 +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: tromey at sourceware dot org 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 #11 from Tom Tromey --- (In reply to Corinna Vinschen from comment #10) > Indeed, this is not necessarily a GDB bug. Apologies, but 8 years ago > it very much looked like a combined ld/GDB problem, that's why I created > https://sourceware.org/bugzilla/show_bug.cgi?id=3D18025 and this bug here > at the same time. Completely understandable, no need to apologize :) > 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? > ...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? 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. 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=