From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5246 invoked by alias); 24 Mar 2006 21:15:32 -0000 Received: (qmail 5236 invoked by uid 22791); 24 Mar 2006 21:15:31 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Mar 2006 21:15:28 +0000 Received: by xproxy.gmail.com with SMTP id t5so634422wxc for ; Fri, 24 Mar 2006 13:15:27 -0800 (PST) Received: by 10.70.63.2 with SMTP id l2mr1848451wxa; Fri, 24 Mar 2006 13:15:26 -0800 (PST) Received: by 10.70.126.10 with HTTP; Fri, 24 Mar 2006 13:15:26 -0800 (PST) Message-ID: <8f2776cb0603241315o22cd4757kb897425cd7606219@mail.gmail.com> Date: Tue, 28 Mar 2006 09:33:00 -0000 From: "Jim Blandy" To: "Andreas Schwab" Subject: Re: gdb and multi-threaded (NPTL) programs Cc: "John Fodor" , gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <44244F1F.6030108@mac.com> <44245BC3.8010706@mac.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00181.txt.bz2 I think some of this discussion is missing the point. A debugger should let the user examine the program's behavior while disturbing it as little as possible. If the debugger happens to be implemented using signals, and those signal disturb the program's behavior, then that's a flaw. The call to sem_wait should probably be wrapped in a loop that checks for EINTR, but that's beside the point. Running the program under the debugger shouldn't even change the number of times the thread goes around the EINTR loop. So I'm agreeing with Daniel, I guess: it's a kernel bug. But it sounds to me like Daniel is saying that you need to find some change to the non-debugging behavior that would also fix the debugging behavior, which I don't agree with. In theory, you should change the debugging behavior and have no effect on the syscall's interface to the code that calls it.