Re: gcore and nptl threads on linux

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Mar 05, 2003 at 12:05:44PM -0500, J. Johnston wrote:
> 
> 
> Daniel Jacobowitz wrote:
> >On Tue, Mar 04, 2003 at 06:40:51PM -0500, J. Johnston wrote:
> >
> >>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.
> >
> >
> >I think this used to cause problems, too - it really should be just the
> >lwpid, I'd think.  For these cases at least.
> >
> >
> >>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.
> >
> >
> >What do you plan to do when there is not a mapping, i.e. in an M:N
> >environment?  This interface assumes 1:1.
> >
> 
> I would think the null_ptid would serve in such a case.

I guess the issue is that we should be dumping the set of LWPs to the
generated core file, not the set of threads.  It seems to me like GDB
should be aware of the list of LWPs, and it shouldn't be hidden in each
individual thread package.

I may be alone in that opinion though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer