This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Enhancement - show old and new thread info when switching during debugging
- From: pfee at talk21 dot com
- To: Pedro Alves <pedro at codesourcery dot com>, gdb-patches at sourceware dot org
- Cc: Joel Brobecker <brobecker at adacore dot com>, Tom Tromey <tromey at redhat dot com>
- Date: Mon, 8 Aug 2011 16:20:30 +0100 (BST)
- Subject: Re: Enhancement - show old and new thread info when switching during debugging
- References: <1311947955.89527.YahooMailRC@web86708.mail.ird.yahoo.com> <1312026270.62521.YahooMailRC@web86705.mail.ird.yahoo.com> <1312803282.12167.YahooMailRC@web86707.mail.ird.yahoo.com> <201108081606.58401.pedro@codesourcery.com>
> > I've looked into convenience variables and have developed a new patch. The
>gdb
>
> > output when switching threads is no longer altered, instead the
>$_prev_thread
>
> > convenience variable can be used to switch back to the previous thread.
> >
> > When making this patch I renamed an existing variable from
> > previous_inferior_ptid to current_inferior_ptid. That way we have values
>that
>
> > move from inferior_ptid (the new ptid) to current_inferior_ptid and finally
>to
>
> > previous_inferior_ptid (which is exposed via the convenience variable).
>This
>
> > seemed better than leaving the variables names as was and introducing
>something
>
> >
> > confusing like previous_previous_inferior_ptid.
>
> Sorry, but current_inferior_ptid for this will be even more confusing.
> There's several current_FOO globals that represent the currently selected
> state. And one of them is "current_inferior". Having current_inferior()
>return
> one thing, and current_inferior_ptid mean another thing will be a recipe
> for long term confusion.
No problem, I'll pick another name.
>
> >
> > By the way, I've made the patches against GDB trunk, I presume that's
>preferred
>
> > over GDB 7.3.
>
> Yes, thanks. 7.3 is in maintenance mode now. New features go to trunk.
That's what I expected, thanks.
>
> >Content-Type: application/octet-stream; name="prev_thread.patch"
> >Content-Transfer-Encoding: base64
> >Content-Disposition: attachment; filename="prev_thread.patch"
>
> Any chance you can convince your mailer to attach patches
> with "Content-Type: text/x-patch" or some other text mime
> type? If you're using a web email account, I think that
> means telling your browser the mime type of the ".patch"
> extension. If you can get it to not use base64, and use
> "content-disposition: inline", you get extra bonus points.
I'm using Yahoo webmail, it's handling of attachments could be better. I'll try
using a traditional email client.
>
> > + /* Values move from interior_ptid to current_inferior_ptid to
> > + * previous_inferior_ptid. The previous value is exposed to the
> > + * user through the $_prev_thread convenience variable.
> > + */
>
> Please no leading * on every comment line. See other
> comments, and follow the same style.
Ok
>
> In order for this to be accepted, it will need some
> documentation in the manual.
>
> I'm not sure the variable is sufficiently well defined yet.
> What does gdb print in this case?
>
> (gdb) thread 2
> (gdb) thread 3
> (gdb) p $_prev_thread
>
> It feels like it should print thread 2, that is, we'd
> define it to the thread the user last had selected,
> and so:
>
> (gdb) thread $_prev_thread
> (gdb) thread $_prev_thread
>
> would cycle between thread 2 and 3.
>
> This definition works for non-stop mode as well.
> Otherwise, as is, we get to define it as "the thread that
> the user had selected the last time an execution command
> was ran" (and the $_prev_thread is undefined/meaningless in
> non-stop mode).
I appreciate the feedback, your summary of the current operation is correct.
I'll take a look at making $_prev_thread be influenced by the user entering
"thread" commands. Since that should then give us consistent operation in both
all-stop and non-stop modes, the additional change will be worthwhile.
Thanks,
Paul