From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7836 invoked by alias); 10 May 2003 21:18:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7829 invoked from network); 10 May 2003 21:18:59 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 10 May 2003 21:18:59 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19EbkY-0006WW-00; Sat, 10 May 2003 16:19:23 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Ebk7-0001EB-00; Sat, 10 May 2003 17:18:55 -0400 Date: Sat, 10 May 2003 21:18:00 -0000 From: Daniel Jacobowitz To: "J. Johnston" , gdb-patches@sources.redhat.com, roland@redhat.com Subject: Re: RFC: nptl threading patch for linux Message-ID: <20030510211855.GA4312@nevyn.them.org> Mail-Followup-To: "J. Johnston" , gdb-patches@sources.redhat.com, roland@redhat.com References: <3EA84E74.3010101@redhat.com> <20030509220011.GA22383@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030509220011.GA22383@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00170.txt.bz2 On Fri, May 09, 2003 at 06:00:11PM -0400, Daniel Jacobowitz wrote: > On Thu, Apr 24, 2003 at 04:52:04PM -0400, J. Johnston wrote: > > The following is the last part of my revised nptl patch that has > > been broken up per Daniel J.'s suggestion. There are no generated > > files included in the patch. > > Well, this patch doesn't work for me :( Using 2.5.69, since I don't > have any of the Red Hat kernels available here at the moment. It looks > like GDB bellies up around the second thread creation. Sorry, I found the problem. Configure was not finding tkill. Entirely a local problem; but how would you feel about something which set the default number for __NR_tkill if __i386__? Or has someone already discouraged that approach? So: > - stop_wait_callback should be fixed to not be so dumb when this > happens. This one is still true. Patch for another day. > - we need to figure out how we got into this mess. > - and why the SIGSTOP never showed up. But these are resolved. I now get fairly good test results with your patch and NPTL; there are some failures because of the vsyscall issue being currently discussed. Backtraces in linux-dp don't work because the threads are stopped in the kernel page. I can also report that the kernel change I am testing to report thread exits does not appear to cause your patch any problems. Yay! More on that in a little while. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer