This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] Fast tracepoint for powerpc64le


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]