From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102991 invoked by alias); 17 Aug 2018 14:28:55 -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 102956 invoked by uid 89); 17 Aug 2018 14:28:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=pursuing, spirit, silent, recalled X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Aug 2018 14:28:53 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CDE4F401EF05; Fri, 17 Aug 2018 14:28:51 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1999E213ED6A; Fri, 17 Aug 2018 14:28:50 +0000 (UTC) Subject: Re: [PATCH] Indicate batch mode failures by exiting with nonzero status To: Gary Benson , Tom Tromey References: <1534425783-11599-1-git-send-email-gbenson@redhat.com> <87r2ix98pk.fsf@tromey.com> <20180817105923.GA32726@blade.nx> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <77a79412-a15c-b69a-fd11-404913e802e4@redhat.com> Date: Fri, 17 Aug 2018 14:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180817105923.GA32726@blade.nx> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-08/txt/msg00424.txt.bz2 On 08/17/2018 11:59 AM, Gary Benson wrote: > Tom Tromey wrote: >>>>>>> "Gary" == Gary Benson writes: >> >> Gary> +/* Did the last invocation of catch_command_errors throw an error? */ >> Gary> + >> Gary> +static bool last_command_failed = false; >> >> catch_command_errors seems to return a boolean, so I think a global >> shouldn't be necessary. > > True. It was a hang up from a previous version of the patch. > I can change it. > >> Also, why just the last command? I mean, I guess I don't really know >> what I would expect, but maybe if any command failed, gdb should exit? > > That was my thinking, to have GDB exit 1 on the first error in batch > mode, but people objected; see the followups to: > > https://sourceware.org/ml/gdb/2018-07/msg00009.html > > The last command thing was something that Pedro wanted. s/wanted/suggested investigating/. > The patch > would originally exit 1 if _any_ error occurred, but Pedro reasoned > that the last operation is the thing you wanted to happen and earlier > failures might be spurious, e.g. bad commands in gdbinit files. Right, and given that, I recalled how TCL handles the return code of procedures that don't have an explicit return, which is that the return code of the last command counts. So I thought that approach was worth investigating. > Though you have situations like: > > bash$ gdb -batch -p 12345 -ex "info sharedlibrary" > ptrace: No such process. > No shared libraries loaded at this time. > bash$ echo $? > 0 As long as GDB runs _both_ commands, I think the "exit status is determined by success/failure of last command run" rule is better. Making GDB exit immediately on first error (and thus not run "info sharedlibrary" in that case) might be worth pursuing as well, maybe with a new command line option, but it seems orthogonal to the exit code rules. > >> Right now there seems to be a discrepancy where if you do "gdb -ex >> fail -ex fail -ex fail", each one will be run; but if you put the >> commands into a file and "gdb -x file", then only the first one will >> be run. I'm not sure if this is good or bad. > > Yeah, it's inconsistent and I hate it :/ I think it depends on perspective. If you put "fail" in a file, and then do "gdb -x file -x file -x file", then "fail" is tried 3 times as well: $ gdb -x file -x file -x file [...] file:1: Error in sourced command file: Undefined command: "fail". Try "help". file:1: Error in sourced command file: Undefined command: "fail". Try "help". file:1: Error in sourced command file: Undefined command: "fail". Try "help". (gdb) > > I wonder if people would accept me changing the default behaviour to > exit 1 on the first error, with an option e.g. -batch-ignore-errors > to revert to the current behaviour. I might reply to the original > thread suggesting that. If we went that route, I'd think that could be a separate orthogonal option. I.e., a "stop/continue processing commands on first error" option. That could be used even without -batch. That would be something in the same spirit of the new "thread apply" / "frame apply" flags: FLAG arguments are -q (quiet), -c (continue), -s (silent). > >> I suppose one nice thing about the "last command only" approach is >> that you could ignore failures by tacking on one more -ex with some >> sort of no-op. > > Every cloud has a silver lining :) > Thanks, Pedro Alves