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

[pfee@talk21.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