pending/1133: gcore and nptl threads on linux

["J. Johnston" <jjohnstn at redhat dot com>]

>Number:         1133
>Category:       pending
>Synopsis:       gcore and nptl threads on linux
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Fri Mar 07 21:58:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 There is a problem with implementing gcore on linux with nptl thread
 support.  Under the linux nptl model, each thread is mapped to an
 lwpid which is distinct from the pid of the process that created the
 thread.
 
 The current linux gcore code is merging the pid with the tid into an unsigned
 long value.  This works ok in the old model because the tid and pids are only
 16-bits in length.  This no longer can work because tids in the nptl model are actually
 addresses and are not restricted to 16-bits.
 
 The kernel has no knowledge of thread ids and generates the corefile prstatus notes
 using the lwpids.  It would be cleaner if the gcore output emulated this
 kernel output.  Now, the gcore code has access to the thread list, but at the
 thread layer, there is no lwp info in the list (just pid and tid info).
 
 At present, the only exposed interface for fetching the lwp from a thread ptid_t
 is the to_pid_to_str() target function.  This converts the ptid to string form
 and will contain the LWP in string form.  To fish this out requires parsing
 the output and converting string to integer.  I have a working example
 of this, but this is considered a bit of an ugly hack.
 
 I would like to propose exposing the lwp_from_thread() functionality currently
 present in the existing threading code.  Notably, thread-db.c has lwp_from_thread(),
 sol-thread.c has thread_to_lwp(), and uw-thread.c has thr_to_lwp() which are all
 static functions.  The default version of this target function would simply return the
 ptid_t input to it.
 
 This change would allow linux-proc.c to get the lwp where possible in a cleaner
 fashion.
 
 If nobody has any major objections to this proposal, I can post a patch shortly.
 
 -- Jeff J.
 
 
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: