This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Thread name in remote stub protocol
- From: <Paul_Koning at Dell dot com>
- To: <palves at redhat dot com>
- Cc: <gdb at sourceware dot org>
- Date: Thu, 25 Jun 2015 13:55:46 +0000
- Subject: Re: Thread name in remote stub protocol
- Authentication-results: sourceware.org; auth=none
- References: <CC0C9FC0-EAF7-4A33-B29B-660557220642 at dell dot com> <558BC9A9 dot 7000505 at redhat dot com>
> 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