This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris)
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