This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD
- From: <Paul_Koning at Dell dot com>
- To: <jhb at freebsd dot org>
- Cc: <gdb-patches at sourceware dot org>, <binutils at sourceware dot org>
- Date: Tue, 12 Jan 2016 19:06:10 +0000
- Subject: Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD
- Authentication-results: sourceware.org; auth=none
- References: <10958096 dot fTGshuKdL7 at ralph dot baldwin dot cx> <5157941 dot xsGge3HdBb at ralph dot baldwin dot cx>
> On Jan 12, 2016, at 1:55 PM, John Baldwin <jhb@freebsd.org> wrote:
>
> On Monday, January 11, 2016 10:53:50 AM John Baldwin wrote:
>> This set of patches adds support for examining kernel-backed user threads on
>> FreeBSD. There is more history in a comment in fbsd-nat.c, but this target
>> uses ptrace directly (instead of libthread_db) to support the current
>> threading library (libthr) on FreeBSD which uses a kernel thread for each
>> user thread. Support for thread names in both core dumps (via FreeBSD's
>> OS-specific NT_THRMISC core note) and live is supported as is scheduler
>> locking. gcore generates register notes for each thread as well.
>>
>> The first two patches are to binutils to support FreeBSD-specific core
>> notes. The last four are to GDB.
>
> (Apologies for fubar'ing the threading on the patches in this series.)
>
> One other note I forgot to mention is that currently I leave the ptid for
> single-threaded processes as (pid, 0, 0) (i.e. I only use LWPs in PTIDs
> when there is more than one thread). What is the best practice? Should
> I always use LWPs in ptids instead?
I would say always use the LWP.
For one thing, the process might start out single-threaded, then at some point midway through the debug session start more threads. If you always use the LWP, the main thread doesn't change identity. But if you fake the PTID to (pid,0,0) then that ID no longer applies once the new thread starts. You'd end up with the confusion of apparently seeing a thread disappear and a new one appear in its place, when in reality that's just the main thread continuing in existence.
paul