From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18955 invoked by alias); 29 Oct 2004 15:22:33 -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 18930 invoked from network); 29 Oct 2004 15:22:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Oct 2004 15:22:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id i9TFMVID021268 for ; Fri, 29 Oct 2004 11:22:31 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9TFMQr14529; Fri, 29 Oct 2004 11:22:26 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4E06F129D8B; Fri, 29 Oct 2004 11:20:54 -0400 (EDT) Message-ID: <41825FD5.1030607@gnu.org> Date: Fri, 29 Oct 2004 15:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Felix Lee Cc: gdb-patches@sources.redhat.com Subject: Re: backtrace changes current source location References: <20041026075115.4A2C354AAB5@stray.canids> <20041026132924.GA26886@nevyn.them.org> <20041026150127.6ED3E54AAB5@stray.canids> <417FDC11.7060700@gnu.org> <20041028005157.259D34E8F0A@stray.canids> In-Reply-To: <20041028005157.259D34E8F0A@stray.canids> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00478.txt.bz2 Hmm, things have changed. Felix Lee wrote: > Andrew Cagney : > >>(Don't forget to consider the error case - if an error is thrown a >>restore would be lost) > > > is it worth setting up an unwind handler for that? I couldn't > think of a case where an error would be usual, and for unusual > errors, all bets are off. As a debugger, we're no longer going to gamble with the user interface - even when there's an error the behavior should be well defined. Can you find out why selected sal is being corrupted, code shouldn't be modifying it. >>Thanks for remembering this. However, as a separate test, it should be >>in a separate file. > > > how about putting the test in list.exp? or is the idea to move > toward one test per file? The latter, if foo.exp passes then feature foo works :-) If you're at a loss for a name, just create a bug report and then call the test gdb.{c,.exp} (we're no longer sharing C files between test cases either :-). Andrew