From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: palves@redhat.com (Pedro Alves)
Cc: cole945@gmail.com (Wei-cheng Wang), gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2] Fast tracepoint for powerpc64le
Date: Tue, 17 Mar 2015 18:12:00 -0000 [thread overview]
Message-ID: <201503171812.t2HICbPn030976@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <54F73D41.9020109@redhat.com> from "Pedro Alves" at Mar 04, 2015 05:13:37 PM
Pedro Alves wrote:
> On 02/27/2015 07:52 PM, Ulrich Weigand wrote:
> > So I guess there's two ways to fix this. One would be to change
> > gdbserver to work more like GDB here. This would involve removing
> > the descriptor->code address conversion in remote.c, and instead
> > performing the conversion in gdbserver's thread_db_enable_reporting.
> > Now, there is no gdbarch_convert_from_func_ptr_addr in gdbserver,
> > so a similar mechanism would have to be invented there. (I guess
> > this would mean a new target hook.) Fortunately, the only platform
> > that uses function descriptors *and* supports libthread_db debugging
> > in gdbserver is ppc64-linux, so we'd only have to add that new
> > mechanim on this platform.
>
> Note sure about this one, ppc64_convert_from_func_ptr_addr wants to
> get at the bfd/binary's unrelocated sections. We'd have to teach
> gdbserver to read the binary.
That's probably not necessary. The reason the GDB implementation
does it that way is that it needs to work under various different
circumstances, like when debugging a core file, or before the
dynamic linker has relocated an executable. For the gdbserver
implementation, we should never need to handle such conditions,
so we are able to simply read the target address from memory.
> (Note for testing: __nptl_create_event will only be used
> on old kernels without PTRACE_EVENT_CLONE, unless you hack the
> code to force usage.)
I wonder why Wei-cheng noticed the problem then ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2015-03-17 18:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 18:04 Wei-cheng Wang
2015-02-25 15:20 ` [PATCH 1/3 v2] " Wei-cheng Wang
2015-03-17 13:34 ` Ulrich Weigand
2015-03-29 19:27 ` Wei-cheng Wang
2015-04-08 16:49 ` Ulrich Weigand
2015-02-27 19:53 ` [PATCH 1/2] " Ulrich Weigand
2015-03-01 17:42 ` Wei-cheng Wang
2015-03-17 13:48 ` Ulrich Weigand
2015-03-04 17:13 ` Pedro Alves
2015-03-17 18:12 ` Ulrich Weigand [this message]
2015-03-17 19:03 ` Pedro Alves
2015-03-18 11:04 ` Ulrich Weigand
2015-03-18 16:07 ` Pedro Alves
2015-03-18 16:53 ` Ulrich Weigand
2015-03-04 17:22 ` Pedro Alves
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=201503171812.t2HICbPn030976@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=cole945@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.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