Re: [rfc][patch] Allow GDB to display user-defined thread names

[Karen Osmond <karen.osmond@gmail.com>]

On Fri, 5 Jun 2009, Tom Tromey wrote:
> >>>>> "Karen" == Karen Osmond <karen.osmond@gmail.com> writes:
> Karen> The new gdb command takes the form "thread name NAME" and
> Karen> associates NAME with the current thread, so you can issue
> Karen> something like:
> 
> It seems like a nice idea to me.  As J.T. says, it would be nice to
> have this automatically work for targets that define a thread name --

Yup, I'll try to find out a bit more about those posix thread extensions.  
Also, I think the Windows way involves throwing a particular exception to 
get the thread name into the debugger, and it looks like gdb doesn't 
support that currently (though i only had a very cursory browse for it).

> but I think it is ok to build up the feature piecemeal.

I'll leave the above and python and MI for now...

> Karen> So, if this is of interest, I'd like to spend the time to improve it but 
> Karen> if anybody has time, it would be of great help if a gdb bod could 
> Karen> volunteer to mentor me a bit... please? :)
> 
> Sure.

Wonderful, thank you!

> Actually, it seems to me that the name-printing should be done by some
> generic code, not in linux-thread-db.c.

Yes, true... and stepping back a level, adding it to target_pid_to_str 
seems wrong also.  Perhaps it is best to make a new function to print the 
thread's id, name and pid_to_str stuff and to call that from the 
appropriate places in thread.c, such as after the thread id in "thread 
info" output.  I think it is also helpful in a few other places like 
[Switching to...] and [New...] and [... exited].  Those don't currently 
include the thread id, but perhaps it makes sense to add that as well (I 
spotted a FIXME-implementors in the manual to that effect, at least for 
[New...]).
 
> One important missing piece is an update to the manual.
> All new user commands require documentation.

I'll make sure to include that in the next patch.

cheers,
-karen