From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: pedro@codesourcery.com (Pedro Alves)
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc] Preferred thread event reporting: Linux native target
Date: Thu, 14 Aug 2008 21:51:00 -0000 [thread overview]
Message-ID: <200808142150.m7ELoMaw023976@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <200808142220.34755.pedro@codesourcery.com> from "Pedro Alves" at Aug 14, 2008 10:20:34 PM
Pedro Alves wrote:
> > -- this is actually simply the currently selected thread
> > (i.e. the current value of inferior_ptid).
>
> Disagreed. inferior_ptid will change if an event happens in
> another thread while you're stepping, but the core decides the event
> was not a good reason to stop. E.g., thread hopping.
Hmm, but if we "thread hop" inferior_ptid should be prefered
anyway (to get the internal "thread hop" action over with as
quickly as possible), and afterwards we're back to the thread
the user is looking at, right?
> > The patch below implements this by adding a new member "preferred" to
> > "struct lwp_info", setting it according to the value of inferior_ptid
> > in linux_nat_resume, and using it (instead of the single-step flag) to
> > decide whether to prefer reporting events in this thread.
>
> I'd prefer to check if an lwp is stepping due to user request, by
> checking struct thread_info's data directly, intead of your
> "prefered" flag.
On the other hand, if the information we need is visible without
relying on inferior_ptid, that would be even nicer.
> Unfortunatelly, currently, GDB doesn't always correctly clear the
> stepping state of all threads when proceeding (clear_proceed_status
> only clears the current thread), but I'm addressing that too in the
> series, see attached.
Great! This is one more thing I wanted to address; thanks for taking
care of it ...
> For my series to go in, every target much register at least the main
> thread in GDB's thread tables, and as it happens, I think AIX
> is the only target I don't have covered, or that I know of
> no one covering.
I can test AIX if necessary. Do you have a patch?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2008-08-14 21:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-14 20:40 Ulrich Weigand
2008-08-14 21:20 ` Pedro Alves
2008-08-14 21:51 ` Ulrich Weigand [this message]
2008-08-15 18:22 ` Michael Snyder
2008-08-18 16:01 ` Ulrich Weigand
2008-08-15 23:28 ` Pedro Alves
2008-08-18 16:23 ` Daniel Jacobowitz
2008-08-18 17:01 ` Ulrich Weigand
2008-08-18 17:04 ` Daniel Jacobowitz
2008-08-18 17:18 ` Pedro Alves
2008-08-18 17:15 ` Pedro Alves
2008-08-18 18:19 ` Ulrich Weigand
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=200808142150.m7ELoMaw023976@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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