From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24665 invoked by alias); 7 Mar 2011 10:45:45 -0000 Received: (qmail 24657 invoked by uid 22791); 7 Mar 2011 10:45:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Mar 2011 10:45:40 +0000 Received: (qmail 2306 invoked from network); 7 Mar 2011 10:45:38 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Mar 2011 10:45:38 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: [PATCH] fix spurious FAIL in py-inferior.exp (x86-solaris) Date: Mon, 07 Mar 2011 10:52:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.1; x86_64; ; ) Cc: Joel Brobecker , gdb-patches@sourceware.org, Mark Kettenis References: <1299238268-32142-1-git-send-email-brobecker@adacore.com> <20110307043923.GN30306@adacore.com> <20110307050445.GA31964@host1.jankratochvil.net> In-Reply-To: <20110307050445.GA31964@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201103071045.34737.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00440.txt.bz2 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}. >=20 > (gdb) info threads=20 > Id Target Id Frame=20 > 10 Thread 4 (LWP 4) start3 (arg=3D0x0) at threadit.c:9 > 9 Thread 3 (LWP 3) start2 (arg=3D0x0) at threadit.c:8 > 8 Thread 2 (LWP 2) start1 (arg=3D0x0) at threadit.c:7 > * 7 Thread 5 (LWP 5) start4 (arg=3D0x0) at threadit.c:10 > 6 LWP 5 start4 (arg=3D0x0) at threadit.c:10 > 5 LWP 4 start3 (arg=3D0x0) at threadit.c:9 > 4 LWP 3 start2 (arg=3D0x0) at threadit.c:8 > 3 LWP 2 start1 (arg=3D0x0) 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). =46rom 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: 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. --=20 Pedro Alves