From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: Ulrich Weigand <uweigand@de.ibm.com>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
Simon Marchi <simon.marchi@ericsson.com>,
Keith Seitz <keiths@redhat.com>,
gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors)
Date: Fri, 08 Dec 2017 11:34:00 -0000 [thread overview]
Message-ID: <19d93119-75cb-435c-9ddb-1f42f6ac8e69@redhat.com> (raw)
In-Reply-To: <867etxpn9k.fsf@gmail.com>
On 12/08/2017 09:44 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> @@ -4309,22 +4309,16 @@ minsym_found (struct linespec_state *self, struct objfile *objfile,
>> struct minimal_symbol *msymbol,
>> std::vector<symtab_and_line> *result)
>> {
>> - struct gdbarch *gdbarch = get_objfile_arch (objfile);
>> - CORE_ADDR pc;
>> struct symtab_and_line sal;
>>
>> - if (msymbol_is_text (msymbol))
>> - {
>> - sal = find_pc_sect_line (MSYMBOL_VALUE_ADDRESS (objfile, msymbol),
>> - (struct obj_section *) 0, 0);
>> - sal.section = MSYMBOL_OBJ_SECTION (objfile, msymbol);
>
> This line is removed, so that sal.section can be null. It causes
> PR 22567. How is the patch below?
That's fine with me. I guess we end up with the wrong section
in the function descriptor / PPC64 case (".opd" instead of some kind
of ".text" where the resolved function lives), but it shouldn't
matter, since the old code did that as well, AFAICT.
(I noticed that get_sal_arch doesn't consider sal.objfile, probably
because it predates addition of the 'obfile' field. We could probably
fill in / use that field more, but we don't need to do that now.)
Pedro Alves
next prev parent reply other threads:[~2017-12-08 11:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-04 18:47 [PATCH 0/2] Make "list ambiguous" show symbol names too Pedro Alves
2017-09-04 18:47 ` [PATCH 2/2] " Pedro Alves
2017-09-06 18:43 ` Keith Seitz
2017-09-04 18:47 ` [PATCH 1/2] Fix "list ambiguous_variable" Pedro Alves
2017-09-06 18:41 ` Keith Seitz
2017-09-20 15:25 ` Pedro Alves
2017-10-16 15:03 ` Simon Marchi
2017-11-25 7:40 ` ppc64 regression: " Jan Kratochvil
2017-11-26 16:38 ` Ulrich Weigand
2017-11-29 19:08 ` [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors) (was: Re: ppc64 regression: [PATCH 1/2] Fix "list ambiguous_variable") Pedro Alves
2017-11-29 19:20 ` [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors) (was: Re: ppc64 regression: [PATCH 1/2] Fix "list amb Ulrich Weigand
2017-11-29 19:28 ` Pedro Alves
2017-12-08 9:44 ` [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors) Yao Qi
2017-12-08 11:34 ` Pedro Alves [this message]
2017-12-08 16:57 ` Yao Qi
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=19d93119-75cb-435c-9ddb-1f42f6ac8e69@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=keiths@redhat.com \
--cc=qiyaoltc@gmail.com \
--cc=simon.marchi@ericsson.com \
--cc=uweigand@de.ibm.com \
/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