[PATCH 0/6] Support kernel-backed user threads on FreeBSD

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 0/6] Support kernel-backed user threads on FreeBSD

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

John Baldwin (6):
  Add support to readelf for reading FreeBSD ELF core notes.
  Add a psuedosection for the NT_FREEBSD_THRMISC note.
  Display per-thread information for threads in FreeBSD cores.
  Use LWP IDs with ptrace register requests on FreeBSD.
  Add support for LWP-based threads on FreeBSD.
  Dump register notes for each thread when generating a FreeBSD core.

 bfd/ChangeLog         |   4 +
 bfd/elf.c             |   7 +
 binutils/ChangeLog    |   5 +
 binutils/readelf.c    |  35 ++++
 gdb/ChangeLog         |  68 ++++++++
 gdb/amd64bsd-nat.c    |  35 ++--
 gdb/config.in         |   3 +
 gdb/configure         |  16 ++
 gdb/configure.ac      |   7 +
 gdb/fbsd-nat.c        | 452 +++++++++++++++++++++++++++++++++++++++++++++++---
 gdb/fbsd-tdep.c       | 185 ++++++++++++++++++---
 gdb/i386bsd-nat.c     |  41 +++--
 gdb/ppcfbsd-nat.c     |  23 ++-
 include/elf/ChangeLog |  27 +++
 include/elf/common.h  |  14 ++
 15 files changed, 842 insertions(+), 80 deletions(-)
 create mode 100644 include/elf/ChangeLog

--
2.7.0
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD

John Baldwin
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?

--
John Baldwin
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD

Mark Kettenis
> From: John Baldwin <[hidden email]>
> Date: Tue, 12 Jan 2016 10:55:34 -0800
>
> 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 think that is the best approach.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD

Paul_Koning
In reply to this post by John Baldwin

> On Jan 12, 2016, at 1:55 PM, John Baldwin <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD

Pedro Alves-7
On 01/12/2016 07:06 PM, [hidden email] wrote:
>
>> On Jan 12, 2016, at 1:55 PM, John Baldwin <[hidden email]> wrote:
>>
>> On Monday, January 11, 2016 10:53:50 AM John Baldwin wrote:

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

We have thread_change_ptid to handle that scenario, but it's indeed best
to avoid it if possible.

Thanks,
Pedro Alves

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 0/6] Support kernel-backed user threads on FreeBSD

John Baldwin
On Tuesday, January 12, 2016 07:24:45 PM Pedro Alves wrote:

> On 01/12/2016 07:06 PM, [hidden email] wrote:
> >
> >> On Jan 12, 2016, at 1:55 PM, John Baldwin <[hidden email]> wrote:
> >>
> >> On Monday, January 11, 2016 10:53:50 AM John Baldwin wrote:
>
> >> 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.
>
> We have thread_change_ptid to handle that scenario, but it's indeed best
> to avoid it if possible.

Yes, I use that now.  However, I will update it to switch to LWPs always
and re-post (with --threaded this time).

--
John Baldwin