Making "info thread" sane

[Andrew Cagney]

>> The interesting thing about George's situation is that there's a lot of
>> threads (basically, all but one of them) that we know in advance will
>> be stuck in context switching code.  One of the nice things about info
>> threads is that it shows you the current frame for all your threads;
>> but in this case, that's not really very interesting information.
>>
>> If we could find out where those threads were _before_ they switched
>> out, now, that would make for an interesting overview.
> 
> 
> Also, I am not apposed to a macro solution.  But, as far as I know the macros are a bit weak.  For example, the info thread command lists the thread number, pid, and an info field (which in my case is the task name from the kernel task struct).  So how would a macro keep this info intact and display it along with the "up" result on the same line?  In my thoughts on this I have considered a maintaince request to the host which would return the pid and the info field, ....

> I also wonder how to determine, when stepping through the threads, that that was the last one.  As far as I know the top thread number is not available as a $var (but that would be nice for other macros as well). 

Sorry, I'm lost here.  Can you perhaphs sketch out how you'd expect GDB, 
the user, and the target to interact?

Andrew