From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8518 invoked by alias); 16 Aug 2010 18:30:36 -0000 Received: (qmail 8508 invoked by uid 22791); 16 Aug 2010 18:30:35 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_GJ,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, 16 Aug 2010 18:30:25 +0000 Received: (qmail 32757 invoked from network); 16 Aug 2010 18:30:24 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Aug 2010 18:30:24 -0000 From: Pedro Alves To: "Ulrich Weigand" Subject: Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread). Date: Mon, 16 Aug 2010 18:30:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201008161738.o7GHceKx024097@d12av02.megacenter.de.ibm.com> In-Reply-To: <201008161738.o7GHceKx024097@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008161930.20550.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: 2010-08/txt/msg00231.txt.bz2 On Monday 16 August 2010 18:38:40, Ulrich Weigand wrote: > Pedro Alves wrote: > > > Index: src/gdb/testsuite/gdb.threads/threxit-hop-specific.exp > [snip] > > +# Set a thread specific breakpoint somewhere the main thread will pass > > +# by, but make it specific to the thread that is going to exit. Step > > +# over the pthread_exit call. GDB should still be able to step over > > +# the thread specific breakpoint, and reach the other breakpoint, > > +# which is not thread specific. > > +set bpthrline [gdb_get_line_number "set thread specific breakpoint here"] > > +gdb_test "break $bpthrline thread 2" \ > > + "Breakpoint .*$srcfile.*$bpthrline.*" \ > > + "set thread specific breakpoint" > > + > > +set bpexitline [gdb_get_line_number "set exit breakpoint here"] > > +gdb_breakpoint "$bpexitline" > > + > > +gdb_test "next" \ > > + ".*set exit breakpoint here.*" \ > > + "get passed the thread specific breakpoint" > > I'm seeing failures in this test on an ARM system with debug info > packages installed for libc / libpthread. The problem is that > pthread_exit is implemented in terms of pthread cancellation, > which under the covers does a longjmp back up to the start_thread > routine in libpthread. > > Normally, GDB will consider this routine to be assembler code and > continue stepping until the end. However, if we actually have > debug info, GDB will stop stepping here (because start_thread > is in fact the parent of the application's thread routine), and > thus the test fails. > > This does look like the correct behaviour under the circumstances, > which would imply the test case is not quite correct. Do you > agree or am I missing something here? I agree. > Any thoughts on how to fix the test? Replacing the "next" by a "continue" should work. I've looked over the original description of the problem this is covering, and, that would still exercise the problem (which is gdb trying to step the other (main) thread with inferior_ptid still pointing at the thread that was being "next"ed, and in the process failing to remove breakpoints from memory because inferior_ptid pointed at an inferior thread. -- Pedro Alves