Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)

[Pedro Alves <pedro@codesourcery.com>]

On Monday 07 March 2011 05:04:45, Jan Kratochvil wrote:
> I do not have a fix but there seems to me mistaken LWP<->PID, each thread gets
> duplicated once as {PID, 0, ID} and once as {PID, ID, 0}.
> 
> (gdb) info threads 
>   Id   Target Id         Frame 
>   10   Thread 4 (LWP 4)  start3 (arg=0x0) at threadit.c:9
>   9    Thread 3 (LWP 3)  start2 (arg=0x0) at threadit.c:8
>   8    Thread 2 (LWP 2)  start1 (arg=0x0) at threadit.c:7
> * 7    Thread 5 (LWP 5)  start4 (arg=0x0) at threadit.c:10
>   6    LWP    5          start4 (arg=0x0) at threadit.c:10
>   5    LWP    4          start3 (arg=0x0) at threadit.c:9
>   4    LWP    3          start2 (arg=0x0) at threadit.c:8
>   3    LWP    2          start1 (arg=0x0) at threadit.c:7
>   2    Thread 1 (LWP 1)  0xfef022f5 in __lwp_wait () from /lib/libc.so.1
>   1    LWP    1          0xfef022f5 in __lwp_wait () from /lib/libc.so.1

It's not a simple "mistake".  Notice how the ids of LWPs are
aligned to the ids of threads.  This was not a coincidence, it
was done on purpose.  This was how solaris thread support
always behaved, up until the pthreads support got completely
broken circa gdb 6.3 and then I restored it a couple of years
ago (see "Modernize solaris threads support" thread).

From Solaris 2 to 8, the default user thread library
used an M:N model.  On v8 a 1:1 implementation appeared,
but it was not made the default (you can select it
at link time).  Solaris 9 switched to 1:1 completely.

Ref: <http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf>

The original author seems to have thought best to
just always expose everything.  I don't know what's
the use case that gets broken if we don't expose
lwps when the threading library is active.  Maybe
something around inactive threads.  Most likely nothing.

-- 
Pedro Alves