This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] Fast tracepoint for powerpc64le
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Wei-cheng Wang <cole945 at gmail dot com>, gdb-patches at sourceware dot org
- Date: Tue, 17 Mar 2015 19:03:03 +0000
- Subject: Re: [PATCH 1/2] Fast tracepoint for powerpc64le
- Authentication-results: sourceware.org; auth=none
- References: <201503171812 dot t2HICbPn030976 at d06av02 dot portsmouth dot uk dot ibm dot com>
On 03/17/2015 06:12 PM, Ulrich Weigand wrote:
> 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.
>
Maybe not cores today, but why doesn't gdbserver have to
handle the case of connecting before the executable has been
relocated?
I also wonder about all the break-interp.exp corner cases.
>> (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 ...
I think he is seeing the problem with the function symbol look ups
gdbserver's tracepoints module does (tracepoint_look_up_symbols),
and that in that case he needs to get the function descriptor
instead of the start of code address? From your previous explanation
I understand that the __nptl_create_event breakpoint (when used)
is set correctly because what gdbserver needs in that case is the start
of code address, which is what remote.c returns.
Thanks,
Pedro Alves