This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 1/2] Fast tracepoint for powerpc64le
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: palves at redhat dot com (Pedro Alves)
- Cc: cole945 at gmail dot com (Wei-cheng Wang), gdb-patches at sourceware dot org
- Date: Tue, 17 Mar 2015 19:12:37 +0100 (CET)
- Subject: Re: [PATCH 1/2] Fast tracepoint for powerpc64le
- Authentication-results: sourceware.org; auth=none
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 ...
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain