From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8518 invoked by alias); 12 Jan 2016 20:52:49 -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 8504 invoked by uid 89); 12 Jan 2016 20:52:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=cfr, mandatory, pij, H*f:sk:047d7b3 X-HELO: mailsec102.isp.belgacom.be Received: from mailsec102.isp.belgacom.be (HELO mailsec102.isp.belgacom.be) (195.238.20.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Jan 2016 20:52:46 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D0AgAXZpVW/5DT81FYBoM6hCGFd7MjAQ2BZIYPAoEsORQBAQEBAQEBgQqENAEBAQMBIzMjBQsIAw4KAgImAgI5HgaIOQyvVJAwAQEBBwIhGWiFVYR/hEaDLoFJBZcTiDaFI4FejR6KYINzIAEBQoIRHIFePYZ4AQEB Received: from 144.211-243-81.adsl-dyn.isp.belgacom.be (HELO soleil) ([81.243.211.144]) by relay.skynet.be with ESMTP/TLS/AES128-GCM-SHA256; 12 Jan 2016 21:52:44 +0100 Message-ID: <1452632099.1672.52.camel@skynet.be> Subject: Re: RFC: block of commands From: Philippe Waroquiers To: Doug Evans Cc: gdb-patches Date: Tue, 12 Jan 2016 20:52:00 -0000 In-Reply-To: <047d7b3a97bc7626e3052915c9f0@google.com> References: <047d7b3a97bc7626e3052915c9f0@google.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00239.txt.bz2 On Mon, 2016-01-11 at 21:40 +0000, Doug Evans wrote: > Heya. > > One feature I've always wanted gdb's cli to have is the > ability to catch errors and be able to continue. > There's always a tension of whether to add things to the cli > or just say "do it in python". gdb scripts are still useful > and thus sometimes I think it's ok to extend the cli, such > as in this case. > Thus instead of /c in this patch I'd prefer something > along the lines of "try ... end". > ["end" is gdb's canonical "trailing }", and I'm all for > Consistency Is Good here.] > The actual details and semantics of "try" I would > leave to a separate thread. For one, I'd have to think > about it some more :-), but I would support someone > wanting to go down that path. > > OTOH, trying to extend the cli's syntax with { and ; is not > something I can support, at least not without more discussion. > This example: > > thread apply all { set $prevsp = $sp; bt \{ p $ebp - $prevsp\; set > $prevsp = $sp \} } > => print the size of each frame > > suggests things could be better; having to escape braces within > subcommands feels excessively error prone. > gdb has one line per command, and changing that > may make things too unwieldly. The { (and have the terminating } optional) was chosen in order to make the interactive typing of a block of command faster/easier. I agree that this new syntax is very different of the 'usual gdb multi-lines terminated by end'. However, multi-lines with end means the user cannot simply type e.g. thread apply all { p i; p j} Instead, the user must type: define pij p i p j end thread apply all pij And after, if the user wants to also print k, then the pij sequence must be retyped (I do not know a way to change/edit/complete a user defined command). An alternative might be to make the terminating } mandatory. Then I think we could get rid of the { and } escaping So, the question is how much we want to make the block of commands easy to use interactively ? Maybe it is not that unusual to have 2 concepts of 'list of commands' : one command per line, with some 'begin/end' keywords several commands per lines, separated by ; (i.e. similar to what a shell is providing with if/fi and ;). The ; separated list versus multi-lines is clearly the main point of discussion. Note that if ever the {}; idea survives, we have to take care about parsing of existing scripts that would do e.g. echo { is an open bracket Not too sure it will be easy to make the {}; idea fully backward compatible :( > There are still > macros so one could still do "thread apply all print-frame-size", > and put the guts of frame size computation in a macro named > print-frame-size. True, but that makes the interactive use and editing not so easy (cfr above). > > Also, I'd prefer to have generally composable commands > over extending individual commands. > E.g., one common thing to do with "thread apply" is backtrace, > as in "thread apply all bt". I like that much better than > if we had extended backtrace to work on each thread. > > Following "Consistency Is Good", and given that we have > "thread apply", for your "bt {/c p i" case how about > something like: > > frame apply all foo Yes, that looks better than adding an optional command to backtrace. Philippe