From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31758 invoked by alias); 6 Oct 2005 17:40:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31664 invoked by uid 22791); 6 Oct 2005 17:40:20 -0000 Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 06 Oct 2005 17:40:20 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Oct 2005 13:40:19 -0400 Message-ID: <3518719F06577C4F85DA618E3C37AB9101CFC7E4@nimbus.ott.qnx.com> From: Kris Warkentin To: 'Michael Snyder' , gdb@sources.redhat.com Subject: re: [RFC] named thread support Date: Thu, 06 Oct 2005 17:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2005-10/txt/msg00031.txt.bz2 > Daniel Jacobowitz wrote: > >On Tue, Oct 04, 2005 at 12:40:22PM -0400, Kris Warkentin wrote: > >> Would it be of interest to have a generic 'set threadname > ' > >> that called a target_set_threadname()? I ask because > we're implementing > >> named threads in our kernel but I don't know if many other systems > >> support this. I can always add it to our backend but if > someone else > >> might use it in the future, I can make it general. > > > > So by named thread support, you mean that the application > can register > > the name of the thread with the kernel? And you want GDB > to be able to > > set thread names? > > > > I recommend doing this in your backend, since I don't know any other > > gdb-supported system with a similar feature. > > On the other hand, this is not the first time I have heard > the idea put forth. Evidently at least some people want > to be able to associate a name with a thread. > > For the sake of discussion, what about this? Split it into > a generic part and a target-specific part. > > 1) The generic part would be to add a name field to gdb's > thread struct, with appropriate UI for manipulating and > displaying it. The "thread" and "thread apply" commands > would be enhanced to accept a name as well as a number. I actually hadn't thought of doing it this way but that's a good idea. I'm using the private_thread_info structure to hold the thread names but if it were part of the higher level thread structure, it would simplify the backend code. > 2) Target-specific part -- sends the gdb-selected names > to the target, accepts target-selected names from the target > and adds them to gdb thread database. Good idea. cheers, Kris