From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7791 invoked by alias); 12 May 2003 19:36:37 -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 7599 invoked from network); 12 May 2003 19:36:36 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 12 May 2003 19:36:36 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 83A81800030; Mon, 12 May 2003 15:36:35 -0400 (EDT) Message-ID: <3EBFF7C3.2000905@redhat.com> Date: Mon, 12 May 2003 19:36:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, roland@redhat.com Subject: Re: RFC: nptl threading patch for linux References: <3EA84E74.3010101@redhat.com> <20030509220011.GA22383@nevyn.them.org> <20030510211855.GA4312@nevyn.them.org> <20030510215939.GA4907@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00191.txt.bz2 Daniel Jacobowitz wrote: > On Sat, May 10, 2003 at 05:18:55PM -0400, Daniel Jacobowitz wrote: > >>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? >> Glad to hear this. >>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. > More good news. > > I could cause segfaults in both the inferior and GDB, and some missed > single-steps. I don't know if my kernel patch is at fault or your > patch, but I figured I'd write them up anyway for posterity and later > review. > > Start with gdb.threads/print-threads. Put a breakpoint on > thread_function and one on the printf ("Done\n") main. Run, disable > the first breakpoint when you hit it, and say next. You'll hit the > breakpoint in main instead of staying within thread_function. > This does not fail on my test system. I end up on line 42 after the next is issued. > This is timing sensitive. It didn't show up with set debug > lin-lwp/target both on. > > In other interesting notes, it looks like there is a (related?) problem > with target_thread_alive. The LWP I'm single-stepping in appears to be > marked as not alive about half the time. No idea what's up with that. > It appears to come from thread_db_thread_alive, not from > lin_lwp_thread_alive, which always succeeds. > > I can't reproduce the SIGSEGV now for some reason. > Have you managed to trace which test in thread_db_alive is returning false? -- Jeff J.