Thread name in remote stub protocol

Thread name in remote stub protocol

[Paul_Koning]

I’ve been looking into FreeBSD threads support, and gdbserver support.  FreeBSD has the notion of thread names, and it’s easy enough to make native GDB handle that.  gdbserver is another matter.  I looked all over the various thread related messages, and while there are a bunch of opportunities for this to be handled, it isn’t really there.

I can see the deprecated qP packet that carries a “shortname”.  That looks interesting, but while the packet parsing is there, it isn’t clear the value goes anywhere.  Similarly, there is qThreadExtraInfo which allows for a free form string.  And there is qXfer:threads, but that carries only an ID and a core number.  And none of these seem to be cleanly tied to the main gdb thread name machinery.

What to do about this?  Could qXfer:threads be extended to add a thread name field?  Or should I just use the ThreadExtraInfo mechanism and ignore the fact that it conveys extra info rather than the thread name?

	paul

Re: Thread name in remote stub protocol

[Pedro Alves]

On 06/24/2015 09:00 PM, Paul_Koning@Dell.com wrote:
> I’ve been looking into FreeBSD threads support, and gdbserver support.  FreeBSD has the notion of thread names, and it’s easy enough to make native GDB handle that.  gdbserver is another matter.  I looked all over the various thread related messages, and while there are a bunch of opportunities for this to be handled, it isn’t really there.
> 
> I can see the deprecated qP packet that carries a “shortname”.  That looks interesting, but while the packet parsing is there, it isn’t clear the value goes anywhere.  Similarly, there is qThreadExtraInfo which allows for a free form string.  And there is qXfer:threads, but that carries only an ID and a core number.  And none of these seem to be cleanly tied to the main gdb thread name machinery.
> 
> What to do about this?  Could qXfer:threads be extended to add a thread name field?  Or should I just use the ThreadExtraInfo mechanism and ignore the fact that it conveys extra info rather than the thread name?

https://sourceware.org/ml/gdb-patches/2015-05/msg00370.html

Thanks,
Pedro Alves

Re: Thread name in remote stub protocol

[Paul_Koning]

> On Jun 25, 2015, at 5:28 AM, Pedro Alves <palves@redhat.com> wrote:
> 
> On 06/24/2015 09:00 PM, Paul_Koning@Dell.com wrote:
>> I’ve been looking into FreeBSD threads support, and gdbserver support.  FreeBSD has the notion of thread names, and it’s easy enough to make native GDB handle that.  gdbserver is another matter.  I looked all over the various thread related messages, and while there are a bunch of opportunities for this to be handled, it isn’t really there.
>> 
>> I can see the deprecated qP packet that carries a “shortname”.  That looks interesting, but while the packet parsing is there, it isn’t clear the value goes anywhere.  Similarly, there is qThreadExtraInfo which allows for a free form string.  And there is qXfer:threads, but that carries only an ID and a core number.  And none of these seem to be cleanly tied to the main gdb thread name machinery.
>> 
>> What to do about this?  Could qXfer:threads be extended to add a thread name field?  Or should I just use the ThreadExtraInfo mechanism and ignore the fact that it conveys extra info rather than the thread name?
> 
> https://sourceware.org/ml/gdb-patches/2015-05/msg00370.html
> 
> Thanks,
> Pedro Alves

Thanks, that looks good.  I don’t see it in GIT, though.

	paul

Re: Thread name in remote stub protocol

[Pedro Alves]

On 06/25/2015 02:55 PM, Paul_Koning@Dell.com wrote:

> Thanks, that looks good.  I don’t see it in GIT, though.

It's going through the review process.  There were some follow
up comments.

Thanks,
Pedro Alves