From: Tom Tromey <tromey@redhat.com>
To: karen.osmond@gmail.com
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc][patch] Allow GDB to display user-defined thread names
Date: Fri, 05 Jun 2009 22:29:00 -0000 [thread overview]
Message-ID: <m3d49is4ar.fsf@fleche.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0906041721010.32368@localhost.localdomain> (Karen Osmond's message of "Thu\, 4 Jun 2009 17\:43\:14 +0100 \(BST\)")
>>>>> "Karen" == Karen Osmond <karen.osmond@gmail.com> 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? :)
Sure.
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.
Tom
next prev parent reply other threads:[~2009-06-05 22:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-04 16:43 Karen Osmond
2009-06-04 16:52 ` J.T. Conklin
2009-06-05 22:29 ` Tom Tromey [this message]
2009-06-05 22:43 ` Paul Pluzhnikov
2009-06-08 14:24 ` Karen Osmond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3d49is4ar.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=karen.osmond@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox