From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8D9123852224; Wed, 23 Nov 2022 17:03:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D9123852224 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669223000; bh=LfIbpKg3NvYY7wvLdRt2sPCWkyhY8tNMiuQQYEs5ojs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QEEOF9ACQmDEMA52uRfu5nnpmF/LvWHCQh6kK3//KjcMymYNKwoaX7Tae/w8YwYVt ss7Ewxk7er9936MN0gmxBbEbaRrDUbJSe0/hEnU7yWvAPn7ZlHDa9j09t8ZZaFNoeK kXYX9pisAS4yzHvIVFkJMQRHQ3zf+H757px3Q6+M= From: "uweigand at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tdep/29814] [gdb/tdep, powerpc64le] FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint Date: Wed, 23 Nov 2022 17:03:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: uweigand at gcc dot gnu.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=3D29814 --- Comment #7 from Ulrich Weigand --- (In reply to Tom de Vries from comment #5) > Now the question is whether there are any synthetic symbols which still n= eed > ppc_elfv2_elf_make_msymbol_special to do something, for instance when > sym->udata.p !=3D NULL, as in ppc64_elf_make_msymbol_special. No, with ELFv2 the only synthetic symbols are related to PLT handling (the = PLT stubs and the __glink_PLTresolve trampoline), and none of those have a local entry point. With ELFv1, there are synthetic symbols for the "dot" symbols (i.e. the real symbol "func" points to the function descriptor, and the synthetic symbol ".func" points to the associated function text). But with ELFv1 there are = no local entry points, so we don't need to handle those. Your fix looks good to me. --=20 You are receiving this mail because: You are on the CC list for the bug.=