From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2192 invoked by alias); 5 Jun 2009 22:29:28 -0000 Received: (qmail 2183 invoked by uid 22791); 5 Jun 2009 22:29:27 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 22:29:22 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n55MTIeS024268; Fri, 5 Jun 2009 18:29:18 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n55MTHhm007006; Fri, 5 Jun 2009 18:29:17 -0400 Received: from opsy.redhat.com (vpn-12-153.rdu.redhat.com [10.11.12.153]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n55MTG51028725; Fri, 5 Jun 2009 18:29:17 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 1CA60378615; Fri, 5 Jun 2009 16:29:16 -0600 (MDT) To: karen.osmond@gmail.com Cc: gdb-patches@sourceware.org Subject: Re: [rfc][patch] Allow GDB to display user-defined thread names References: From: Tom Tromey Reply-To: tromey@redhat.com Date: Fri, 05 Jun 2009 22:29:00 -0000 In-Reply-To: (Karen Osmond's message of "Thu\, 4 Jun 2009 17\:43\:14 +0100 \(BST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00142.txt.bz2 >>>>> "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? :) 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