From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: palves@redhat.com (Pedro Alves)
Cc: jan.kratochvil@redhat.com (Jan Kratochvil),
simon.marchi@ericsson.com (Simon Marchi),
keiths@redhat.com (Keith Seitz),
gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors) (was: Re: ppc64 regression: [PATCH 1/2] Fix "list amb
Date: Wed, 29 Nov 2017 19:20:00 -0000 [thread overview]
Message-ID: <20171129191948.A7DF7D80320@oc3748833570.ibm.com> (raw)
In-Reply-To: <0bea6805-b8eb-da2c-07f6-0f1ee917c7b5@redhat.com> from "Pedro Alves" at Nov 29, 2017 07:07:54 PM
Pedro Alves wrote:
> On 11/26/2017 04:37 PM, Ulrich Weigand wrote:
>
> > I now see this as well on Cell/B.E. This is a serious regression that
> > causes "start" to always fail for me ...
> >
> > The problem seems to be that GDB sets a breakpoint into the function
> > descriptor for main, which is not a good idea.
> >
> > Looking at the commit identified above, it seems that GDB now only
> > runs the address through gdbarch_convert_from_func_ptr_addr if
> > msymbol_is_text returns true. However, if the symbol points to
> > a function descriptor, msymbol_is_text would be false since this
> > is in fact outside the text section.
> >
> > So I think probably we need to still run the address through
> > gdbarch_convert_from_func_ptr_addr, and if that detects that it
> > was indeed a function descriptor, always treat the resulting
> > address as a function.
>
> Thanks for the suggestion. Here's a patch that implements
> something like that. WDYT?
Yes, this looks all good to me. Thanks for taking care of this!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2017-11-29 19:20 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 ` Ulrich Weigand [this message]
2017-11-29 19:28 ` [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors) (was: Re: ppc64 regression: [PATCH 1/2] Fix "list amb 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
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=20171129191948.A7DF7D80320@oc3748833570.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=keiths@redhat.com \
--cc=palves@redhat.com \
--cc=simon.marchi@ericsson.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