Re: Enhancement - show old and new thread info when switching during debugging

[Pedro Alves <pedro at codesourcery dot com>]

Hellow,

On Monday 08 August 2011 12:34:42, pfee@talk21.com wrote:

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

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

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

> + /* 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.
> +  */

Plese no leading * on every comment line.  See other
comments, and follow the same style.

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

-- 
Pedro Alves