RE: [RFC] named thread support

RE: [RFC] named thread support

[Kris Warkentin]

> On Tue, Oct 04, 2005 at 12:40:22PM -0400, Kris Warkentin wrote:
> > Would it be of interest to have a generic 'set threadname 
> <tid> <name>' 
> > 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?

Exactly.  When I implemented the reading of the names from the target it
occurred to me that I could set names as well.  It's not a super useful or
high priority item but it's easy and fun so I thought I'd do it anyway. ;-)

> I recommend doing this in your backend, since I don't know any other
> gdb-supported system with a similar feature.

No problem.

cheers,

Kris

RE: [RFC] named thread support

[Kris Warkentin]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> On Thu, Oct 06, 2005 at 11:30:22AM -0700, Stan Shebs wrote:
> > Kris Warkentin wrote:
> > 
> > >Would it be of interest to have a generic 'set threadname <tid> 
> > ><name>' 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.
> > 
> > This actually was on the wishlist ages ago, ca 1998 or so I think,
> > probably connected with eCos plans. Even a target that didn't
> > support named threads could still make use of the generic 
> capability,
> > for instance via setup scripts - break at a place known unique to a
> > particular thread, get tid, name it, then user and other scripts can
> > reliably use the name.
> 
> I find this much more interesting than the way I interpreted Kris's
> original question - I don't think many targets will be interested in
> propogating the thread name to the target, but more will be interested
> in retrieving the thread name from the target, and all will be
> interested in user-defined names in the interface.  Let's do it! :-)

Cool.  We're putting another person on our gdb team (Jeff Baker who you
might know from the binutils mailing list) so he and I will work on this.
Sounds like a fun project.

cheers,

Kris

re: [RFC] named thread support

[Kris Warkentin]

> Daniel Jacobowitz <drow at false dot org> 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 
> <tid> <name>'
> >> 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

Re: [RFC] named thread support

[Michael Snyder]

Daniel Jacobowitz <drow at false dot org> 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 <tid> <name>'
>> 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.

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.

Part 1 could be used by everybody, independently of
whether their target implements part 2.

Michael

Re: [RFC] named thread support

[Ramana Radhakrishnan]

Hi,


<snipped>

> 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.

That sounds neat in terms of user interface. Associating meaningful
names with threads rather than viewing them in terms of thread id's
would enhance user experience.  

> 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.
> 
> Part 1 could be used by everybody, independently of
> whether their target implements part 2.
> 
> Michael
> 
-- 
Ramana Radhakrishnan                                            
GNU Tools,
codito ergo sum (http://www.codito.com)

Office:+91 20 26051367 ext. 162  Mobile:+91 9890040009
                                                                        

[RFC] named thread support

[Kris Warkentin]

Would it be of interest to have a generic 'set threadname <tid> <name>' 
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.

cheers,

Kris

-- 
Stay up-to-date on all the QNX news!  Register at
http://www.qnx.com/news/forms/newsletter.html to
receive our newsletter.

Re: [RFC] named thread support

[Daniel Jacobowitz]

On Tue, Oct 04, 2005 at 12:40:22PM -0400, Kris Warkentin wrote:
> Would it be of interest to have a generic 'set threadname <tid> <name>' 
> 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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC] named thread support

[Mark Kettenis]

> Date: Wed, 5 Oct 2005 21:21:39 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> On Tue, Oct 04, 2005 at 12:40:22PM -0400, Kris Warkentin wrote:
> > Would it be of interest to have a generic 'set threadname <tid> <name>' 
> > 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.

I think HP-UX allows you to do the same thing, and many user-space
threads implementations allow you to do something very similar.

Mark

Re: [RFC] named thread support

[Daniel Jacobowitz]

On Sun, Oct 09, 2005 at 10:34:41PM +0200, Mark Kettenis wrote:
> > Date: Wed, 5 Oct 2005 21:21:39 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> >
> > On Tue, Oct 04, 2005 at 12:40:22PM -0400, Kris Warkentin wrote:
> > > Would it be of interest to have a generic 'set threadname <tid> <name>' 
> > > 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.
> 
> I think HP-UX allows you to do the same thing, and many user-space
> threads implementations allow you to do something very similar.

Well then :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC] named thread support

[Stan Shebs]

Kris Warkentin wrote:

> Would it be of interest to have a generic 'set threadname <tid> 
> <name>' 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.

This actually was on the wishlist ages ago, ca 1998 or so I think,
probably connected with eCos plans. Even a target that didn't
support named threads could still make use of the generic capability,
for instance via setup scripts - break at a place known unique to a
particular thread, get tid, name it, then user and other scripts can
reliably use the name.

Stan

Re: [RFC] named thread support

[Daniel Jacobowitz]

On Thu, Oct 06, 2005 at 11:30:22AM -0700, Stan Shebs wrote:
> Kris Warkentin wrote:
> 
> >Would it be of interest to have a generic 'set threadname <tid> 
> ><name>' 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.
> 
> This actually was on the wishlist ages ago, ca 1998 or so I think,
> probably connected with eCos plans. Even a target that didn't
> support named threads could still make use of the generic capability,
> for instance via setup scripts - break at a place known unique to a
> particular thread, get tid, name it, then user and other scripts can
> reliably use the name.

I find this much more interesting than the way I interpreted Kris's
original question - I don't think many targets will be interested in
propogating the thread name to the target, but more will be interested
in retrieving the thread name from the target, and all will be
interested in user-defined names in the interface.  Let's do it! :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC