From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D84AA385800A; Thu, 17 Feb 2022 18:44:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D84AA385800A From: "development at efficientek dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/28900] GDB crash on loading symbols form openbios binary Date: Thu, 17 Feb 2022 18:44:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: 11.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: development at efficientek dot com 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 18:44:24 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28900 --- Comment #6 from Glenn Washburn --- (In reply to Simon Marchi from comment #3) > PowerPC64 defines _GLOBAL like this: >=20 > #define _GLOBAL(name) \ > .align 2 ; \ > .type name,@function; \ > .globl name; \ > name: >=20 > I guess this generates an ELF function/text symbol, which is enough to be > able to put a breakpoint on it or print its address. It's only PowerPC32 > that does: >=20 > #define _GLOBAL(n) \ > .stabs __stringify(n:F-1),N_FUN,0,0,n;\ > .globl n; \ > n: >=20 > Is there a reason that PowerPC32 can't do the same as PowerPC64, let the > compiler generate an ELF function/text symbol for the label? I don't know the answer to that, as this isn't really my area (not very familiar with the architecture nor debugging formats). My suspicion is that there is no reason. When I remove the .stabs directive and load the binary = into GDB, it sees the generated symbols using "info symbol" and "p &". I just don't know if I'm losing debugging capability by doing this (eg. not a= ble to call those functions). It seems odd to me that whoever added this PPC 64-bit code to the kernel wouldn't have used common code if that was a reasonable thing to do. So may= be it not that simple. And yes, of course a fix in GDB would be great. I also understand that ther= e's probably low motivation as this is an ancient format, so a fix will not lik= ely be forth coming soon. I also don't expect stabs support to be removed anyti= me soon, as there's always people on legacy software and they'll probably want= to keep what's there. --=20 You are receiving this mail because: You are on the CC list for the bug.=