From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11394 invoked by alias); 2 Dec 2008 01:20:52 -0000 Received: (qmail 11384 invoked by uid 22791); 2 Dec 2008 01:20:51 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Dec 2008 01:20:16 +0000 Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id mB21KEYg025713 for ; Mon, 1 Dec 2008 17:20:14 -0800 Received: from rv-out-0708.google.com (rvbf25.prod.google.com [10.140.82.25]) by wpaz17.hot.corp.google.com with ESMTP id mB21KCEJ012979 for ; Mon, 1 Dec 2008 17:20:13 -0800 Received: by rv-out-0708.google.com with SMTP id f25so2596541rvb.32 for ; Mon, 01 Dec 2008 17:20:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.247.13 with SMTP id u13mr5490387rvh.288.1228180812572; Mon, 01 Dec 2008 17:20:12 -0800 (PST) In-Reply-To: <200812012121.59580.pedro@codesourcery.com> References: <20081118125838.0613C412301@localhost> <200812012121.59580.pedro@codesourcery.com> Date: Tue, 02 Dec 2008 01:20:00 -0000 Message-ID: Subject: Re: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement From: Doug Evans To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2008-12/txt/msg00023.txt.bz2 On Mon, Dec 1, 2008 at 1:21 PM, Pedro Alves wrote: > Hi Doug, > > I'd like to bring a current GDB deficiency to your attention, in > case it affects anything related to this patch. > > If GDB stops due to a signal instead of hitting the dummy frame > breakpoint, and you have set GDB to restore the state > automatically with "set unwindonsignal on", and the thread > that reported the signal (say a SIGSEGV) was *not* the same that was > doing the infcall, GDB will currently restore the old context to the > wrong thread (seen by inspection, having really tried it). > > Not having studied the patch yet, I'm just wondering if your changes > would make it easier or harder to fix this, or if you could be > extending the problem by possibly restoring things in the wrong > thread as well. Heh. My patch serendipitously has the following to catch another case I was seeing where the current thread unexpectedly changed. if (! ptid_equal (this_thread->ptid, inferior_thread ()->ptid)) { /* We've switched threads. Perhaps this shouldn't happen, but we protect ourselves anyway. There's no point in restoring the inferior status, we're in a different thread. */ discard_cleanups (inf_status_cleanup); discard_inferior_status (inf_status); dummy_frame_discard (dummy_frame); error (_("\ The current thread has switched while making a function call from GDB.\n\ The state of the function call has been lost.\n\ It may be recoverable by changing back to the original thread\n\ and examining the state.")); } I need fix my patch to save the calling thread's ptid (this_thread->ptid) before resuming execution in case the thread dies. I think I shouldn't call dummy_frame_discard here too. And I also need to change the comment to document why the current thread can switch, because it _can_ happen. :-) I'll prepare a new version of my patch, and include a testcase to handle the situation you mention. Thanks!