public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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: Wed, 18 Mar 2015 11:04:00 -0000	[thread overview]
Message-ID: <201503181104.t2IB4bne004457@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <55087A67.1070403@redhat.com> from "Pedro Alves" at Mar 17, 2015 07:03:03 PM

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

  reply	other threads:[~2015-03-18 11:04 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
2015-03-17 19:03       ` Pedro Alves
2015-03-18 11:04         ` Ulrich Weigand [this message]
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=201503181104.t2IB4bne004457@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).