From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24542 invoked by alias); 12 Dec 2014 10:47:39 -0000 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 Received: (qmail 24518 invoked by uid 89); 12 Dec 2014 10:47:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 12 Dec 2014 10:47:36 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBCAlXCQ010378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Dec 2014 05:47:33 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBCAlVuk029509; Fri, 12 Dec 2014 05:47:32 -0500 Message-ID: <548AC7C3.9020000@redhat.com> Date: Fri, 12 Dec 2014 10:47:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mark Wielaard , Stan Shebs CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Use GCC5/DWARF5 DW_AT_noreturn to mark functions that don't return normally. References: <1417099980-31834-1-git-send-email-mjw@redhat.com> <5480696F.1060308@redhat.com> <1418122161.18974.42.camel@bordewijk.wildebeest.org> <548745FD.40000@earthlink.net> <1418210696.5011.10.camel@bordewijk.wildebeest.org> In-Reply-To: <1418210696.5011.10.camel@bordewijk.wildebeest.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00269.txt.bz2 On 12/10/2014 11:24 AM, Mark Wielaard wrote: > Hi Stan, > > On Tue, 2014-12-09 at 10:57 -0800, Stan Shebs wrote: >> On 12/9/14, 2:49 AM, Mark Wielaard wrote: >>> On Thu, 2014-12-04 at 14:02 +0000, Pedro Alves wrote: >>>> I wonder if we could have a test? Could e.g., make sure we don't >>>> crash when the user confirms a return in a noreturn function. >>> >>> I am not sure how to write such a test. This is mainly interactive code, >>> which will only trigger from_tty. I also am not sure such a test really >>> tests this new feature. Trying to return from a noreturn function >>> triggers undefined behavior. GDB probably won't crash, but the inferior >>> might since the result is unpredictable (that is precisely why I added >>> this, you forcibly return from a function and end up somewhere >>> unexpected). Which makes testing the expected output of the user >>> ignoring the warning somewhat hard. >> >> Chiming in here, just write the test so that it passes whether or not >> the inferior crashes - as you note, its behavior is undefined anyway. >> If GDB crashes or hangs, on any platform, that's a bug that we have to >> fix in GDB. > > I am afraid I still don't understand what we would be testing (whether > the user if there is a tty gets to say yes or no?) or how to write such > a test where we don't seem interested in the actual result. Is there an > example to follow? The point is just to test the new/related code paths, and making sure the commands do what you propose they do. E.g., to make sure the new dwarf code (and future changes around it) don't crash. And then in the "return->no" path, make sure we really cancel the command (that the backtrace looks the same after canceling), which also potentially exercises bad/missing cleanups, for example. By testing the "return->yes" path, we'd be making sure the unwinder doesn't crash (now and in the future) in this situation, and that the current frame ends up being the one expected. For the "finish" case, we'd be making sure that GDB doesn't crash when trying to figure out where the function's return value is stored ("finish" prints the function's return value when the function actually finishes). There are some tests for "return" in the testsuite -- return.exp or return2.exp -- and at least one for "finish" -- finish.exp. I'd suggest using these as inspiration. Thanks, Pedro Alves