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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Pedro Alves wrote:
> On 03/17/2015 06:12 PM, Ulrich Weigand wrote:
> > 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.

gdbserver would access function descriptors only for the
__nptl_create_event etc. routines.  These are looked up
only after a libthread_db td_ta_new_p call succeeds, which
should only be true if libpthread has been loaded (and
relocated) in the inferior.  If it hasn't been yet at the
time gdbserver attaches, the whole thread initialization
sequence is defered until after the new_objfile event that
happens after libpthread *was* loaded and relocated.
Am I missing something here?

Maybe if in the future additional function descriptor lookups
are added to gdbserver, we could run into that issue.

In any case, the other solution is probably better anyway.


> >> (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.

Ah, of course.  Sorry for the confusion.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com