public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "uweigand at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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 [thread overview]
Message-ID: <bug-29814-4717-oHaELf9fd6@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29814-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=29814
--- Comment #7 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> Now the question is whether there are any synthetic symbols which still need
> ppc_elfv2_elf_make_msymbol_special to do something, for instance when
> sym->udata.p != 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2022-11-23 17:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 13:27 [Bug tdep/29814] New: " vries at gcc dot gnu.org
2022-11-21 16:32 ` [Bug tdep/29814] " vries at gcc dot gnu.org
2022-11-23 10:14 ` vries at gcc dot gnu.org
2022-11-23 11:11 ` vries at gcc dot gnu.org
2022-11-23 11:59 ` uweigand at gcc dot gnu.org
2022-11-23 16:16 ` vries at gcc dot gnu.org
2022-11-23 16:37 ` cel at us dot ibm.com
2022-11-23 17:03 ` uweigand at gcc dot gnu.org [this message]
2022-11-23 20:43 ` cel at us dot ibm.com
2022-11-24 12:45 ` vries at gcc dot gnu.org
2022-11-28 9:50 ` cvs-commit at gcc dot gnu.org
2022-11-28 9:51 ` vries at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-29814-4717-oHaELf9fd6@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=gdb-prs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).