From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17045 invoked by alias); 14 Jan 2009 15:07:59 -0000 Received: (qmail 17037 invoked by uid 22791); 14 Jan 2009 15:07:58 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.29.156) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Jan 2009 15:06:59 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id n0EF6K2Q520052 for ; Wed, 14 Jan 2009 15:06:20 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 v9.1) with ESMTP id n0EF6KRf2068524 for ; Wed, 14 Jan 2009 16:06:20 +0100 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 n0EF6JdQ014246 for ; Wed, 14 Jan 2009 16:06:20 +0100 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 n0EF6JPS014241; Wed, 14 Jan 2009 16:06:19 +0100 Message-Id: <200901141506.n0EF6JPS014241@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 14 Jan 2009 16:06:19 +0100 Subject: Re: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement To: dje@google.com (Doug Evans) Date: Wed, 14 Jan 2009 15:07:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, pedro@codesourcery.com In-Reply-To: from "Doug Evans" at Jan 07, 2009 08:36:32 AM 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: 2009-01/txt/msg00320.txt.bz2 Doug Evans wrote: > I also meant to ask another question. > What's the intended handling of unwindonsignal if the program stops in > another thread? > Should the inferior function call in the original thread be unwound? > GDB's current behavior is busted as it pops the dummy frame on the wrong thread. > This patch doesn't unwind the dummy frame (so at least it doesn't > clobber the wrong thread), but I can change it to unwind the dummy > frame of the original thread if you like. I think the behaviour implemented by your patch is reasonable. Ideally, you'd probably want to delay handling events in other threads until execution of the inferior call has completed. That may be nontrivial to implement, however ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com