From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24574 invoked by alias); 16 Aug 2010 17:38:52 -0000 Received: (qmail 24561 invoked by uid 22791); 16 Aug 2010 17:38:51 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.17.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Aug 2010 17:38:46 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.1/8.13.1) with ESMTP id o7GHcgNi001489 for ; Mon, 16 Aug 2010 17:38:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7GHcgKX3809472 for ; Mon, 16 Aug 2010 19:38:42 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o7GHcgcV024104 for ; Mon, 16 Aug 2010 19:38:42 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o7GHceKx024097; Mon, 16 Aug 2010 19:38:41 +0200 Message-Id: <201008161738.o7GHceKx024097@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 16 Aug 2010 19:38:40 +0200 Subject: Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread). To: pedro@codesourcery.com (Pedro Alves) Date: Mon, 16 Aug 2010 17:38:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200905272300.28249.pedro@codesourcery.com> from "Pedro Alves" at May 27, 2009 11:00:27 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00224.txt.bz2 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? Any thoughts on how to fix the test? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com