From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28070 invoked by alias); 9 Dec 2014 18:57:05 -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 28060 invoked by uid 89); 9 Dec 2014 18:57:04 -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,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-junco.atl.sa.earthlink.net Received: from elasmtp-junco.atl.sa.earthlink.net (HELO elasmtp-junco.atl.sa.earthlink.net) (209.86.89.63) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Dec 2014 18:57:03 +0000 Received: from [68.104.56.205] (helo=macbook2.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XyPy1-0001EE-Oz for gdb-patches@sourceware.org; Tue, 09 Dec 2014 13:57:01 -0500 Message-ID: <548745FD.40000@earthlink.net> Date: Tue, 09 Dec 2014 18:57:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 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> In-Reply-To: <1418122161.18974.42.camel@bordewijk.wildebeest.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94094c1b42350c32fe48185d78bf34c0b57350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00201.txt.bz2 On 12/9/14, 2:49 AM, Mark Wielaard wrote: > On Thu, 2014-12-04 at 14:02 +0000, Pedro Alves wrote: >> On 11/27/2014 02:53 PM, Mark Wielaard wrote: >>> Add a flag field is_noreturn to struct func_type. Make calling_convention >>> a small bit field to not increase the size of the struct. Set is_noreturn >>> if the new GCC5/DWARF5 DW_AT_noreturn is set on a DW_TAG_subprogram. >>> Use this information to warn the user before doing a finish or return from >>> a function that does not return normally to its caller. >>> >>> (gdb) finish >>> Warning. Function endless does not return normally. >>> Try to finish anyway? (y or n) >>> >>> (gdb) return >>> warning: Function does not return normally to caller! >>> Make endless return now? (y or n) >> >> I'd suggest making the warnings a bit more consistent. >> >> - "Warning." vs "warning: " >> >> Prefer the latter, as that's what the "warning" function uses. >> >> - "." vs "!" >> >> I'd keep it calm and get rid of the "!". :-) > > Fixed both. > >>> >>> gdb/ChangeLog >>> >>> * dwarf2read.c (read_subroutine_type): Set TYPE_NO_RETURN from >>> DW_AT_noreturn. >>> * gdbtypes.h (struct func_type): Add is_noreturn field flag. Make >>> calling_convention an 8 bit bit field. >>> (TYPE_NO_RETURN): New macro. >>> * infcmd.c (finish_command): Query if function does not return >>> normally. >>> * stack.c (return_command): Likewise. >>> >>> include/ChangeLog >>> >>> * dwarf2.def (DW_AT_noreturn): New DWARF5 attribute. >> >> 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. Stan stan@codesourcery.com