This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

>>>>> "Karen" == Karen Osmond <> writes:

Karen> When debugging programs with posix threads, it often makes me
Karen> sad that the threads don't have any meaningful name associated
Karen> with them.

GDB 7.0, now with more happiness ;)

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 --
but I think it is ok to build up the feature piecemeal.

Karen> I attach a patch for the "thread name" command functionality.
Karen> Despite its small size, I know it will need improvement - at
Karen> very least I doubt it is good style to expose language /
Karen> valprint stuff in thread.c.

Actually, I don't think that is such a big deal.  The implementation
of user commands often needs this functionality.

Karen>  - Thread names aren't known at the point gdb issues a "New thread..." 
Karen> notification, and initial "Switching to...".

This could be handled with J.T.'s idea, or...

Karen>  - Maybe the script could be done better with python - I
Karen> haven't yet tried the python stuff in gdb.

... a python hook run when a thread is created.

Karen>  - It would be good to get this working with MI.

I think this should not be too difficult.

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? :)


Karen> !       if (thread_info->name == NULL)
Karen> !         snprintf (buf, sizeof (buf), "Thread 0x%lx (LWP %ld)",
Karen> !                   tid, GET_LWP (ptid));
Karen> !       else
Karen> !         snprintf (buf, sizeof (buf), "Thread [%s] 0x%lx (LWP %ld)", 
Karen> !                   thread_info->name, tid, GET_LWP (ptid));

I think you will at least want to make 'buf' bigger.  But, probably
you want to dynamically allocate instead.

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

One important missing piece is an update to the manual.
All new user commands require documentation.

Otherwise I think it looks pretty reasonable.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]