Re: thread ptids when debugging from core file (x86-linux)

[Marcel Moolenaar <marcel@xcllnt.net>]

On Fri, Aug 06, 2004 at 03:10:52PM -0400, Nathan J. Williams wrote:
> Marcel Moolenaar <marcel@xcllnt.net> writes:
> 
> The Linux thread code (thread-db.c) already knows how to poke around
> in memory and find all the threads. That memory also includes the
> thread-to-LWP mapping, in some form. The trick is getting the process
> callbacks in proc-service.c to look up registers of LWPs in the
> matching core file section.

Yes.

> On Solaris and NetBSD, the .reg/NNN sections have NNN values equal to
> PID + (LWPID << 16), so it's straightforward to map from a LWP to a
> core section. I'm not sure how Linux names them.

This doesn't work on FreeBSD and I also don't think it works on Linux.
PIDs go beyond 2^16, and LWPIDs are higher numbered than PIDs on FreeBSD.
I solved it on FreeBSD (which given the release schedule means that
impact had to be minimal) by using the PID field in the note section to
hold the LWPID and redefinition inferior_ptid in the proc_service "layer"
to use the LWPID as the PID. This yielded a minimal impact for the core,
inferior and remote targets as well as the ptrace(2) syscall.

> It also helps to use init_thread_list() to blow away the list that
> corelow.c generates.

I happen to do that on FreeBSD as well, but that's mostly because of
MxN threading. For unbound threads the correlation between LWPID and
TID is non-constant and there's significant overhead to have the PTID
include both. So, the PTID only has the TID (and of course the PID,
but that's constant), which means that the thread list created by
corelow, which has the LWPID in the PID field on FreeBSD, needs to
be replaced by a thread list that has TID filled in. For 1xN or 1x1
threading you don't have to throw away the thread list that corelow.c
creates, but the purpose of libthread_db is to abstract the difference
so we don't try to avoid it :-)

Anyway, to get back to Joel's original mail: a logical solution that
would minimize knowledge of the threading implementation is to use
the libthread_db API to access thread information, and to keep the
Ada task to TID mapping inside the Ada-tasks layer. If the Ada-tasks
layer is a target on top of the thread target, then it makes sense
to have the thread list in GDB use Ada-tasks specific IDs. It may
then even be possible to use target_beneath->[method]() without
having to use the libthread_db API.

Put differently, one can view the Ada-tasks layer as a 1:1 threading
target on top of the threads target.

Just a thought,

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net