From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20261 invoked by alias); 27 Jul 2019 20:47:23 -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 20248 invoked by uid 89); 27 Jul 2019 20:47:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*c:US-ASCII, ordinary, shuts, critique 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 ESMTP; Sat, 27 Jul 2019 20:47:21 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C73703082120; Sat, 27 Jul 2019 20:47:20 +0000 (UTC) Received: from f29-4.lan (ovpn-118-27.phx2.redhat.com [10.3.118.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9B25B1001B04; Sat, 27 Jul 2019 20:47:20 +0000 (UTC) Date: Sat, 27 Jul 2019 20:47:00 -0000 From: Kevin Buettner To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] Add -P command line switch for executing Python scripts Message-ID: <20190727134719.36b7ccaa@f29-4.lan> In-Reply-To: <87sgqwv6ql.fsf@tromey.com> References: <20190721235427.21893-1-kevinb@redhat.com> <20190721235427.21893-3-kevinb@redhat.com> <87sgqwv6ql.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00622.txt.bz2 On Tue, 23 Jul 2019 14:25:06 -0600 Tom Tromey wrote: > >>>>> "Kevin" == Kevin Buettner writes: > > Kevin> This commit introduces a new command line switch to GDB, a -P / > Kevin> --python switch which is used for executing a python script. > Kevin> Encountering -P curtails normal argument processing by GDB; any > Kevin> remaining arguments (after the script name) are passed to the > Kevin> script. > > Kevin> 1) After script execution, exit() was called which (obviously) > Kevin> caused GDB to exit. > Kevin> 2) The printing of GDB's banner (copyright info, bug reporting > Kevin> instructions, and help instructions) was suppressed. > Kevin> 3) Due to the exit() noted above, GDB's CLI was not (automatically) > Kevin> invoked. If the CLI was desired, it could be run from the Python > Kevin> script via use of the gdb.cli method, which was added as part of > Kevin> that work. > > Kevin> I've changed things so that exit() is no longer called. GDB's CLI > Kevin> will be invoked after script execution. Also, GDB's banner will be > Kevin> printed (or not) as normal. I.e, the banner will be printed unless > Kevin> the -q switch is specified. > > Kevin> If the script doesn't want the CLI for some reason, it can explicitly > Kevin> call exit(). It may be the case that the script would be better off > Kevin> calling a (yet to be written) gdb.exit() method for doing this > Kevin> instead. Such a method could make sure that GDB shuts down properly. > > The intent of -P was to provide a way to run gdb in a "Python script" > mode. I think this changes defeat this goal. > > For (2), printing the banner is just not great for an interpreter. The > default for interpreters should be silence, with the script being > interpreted choosing what to emit. "-q" isn't sufficient because it is > common for #! handling to only allow a single argument. > > I think if -P is going to just mean "start gdb, but interpret some > Python script at startup", then it might as well not exist -- an > invocation like '-ex "source blah.py"' is just as good, and can be used > on older gdbs as well. > > (1) and (3) seem linked. Here the idea was to have a way to script gdb > where the command line was completely optional and under control of the > script. > > Maybe -P isn't the right vehicle for this. Later on, I was looking at > having a "Python" gdb interpreter -- not to actually interpret gdb > input, but to at least control gdb output. And, I looked into compiling > gdb PIE so that one could just "import gdb" from an ordinary Python > interpreter. Thanks for that critique / explanation. I'm going to mull this over some more... Kevin