From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38195 invoked by alias); 23 Jul 2019 20:25:11 -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 37824 invoked by uid 89); 23 Jul 2019 20:25:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SEMBLACK,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=vehicle X-HELO: gateway23.websitewelcome.com Received: from gateway23.websitewelcome.com (HELO gateway23.websitewelcome.com) (192.185.49.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Jul 2019 20:25:09 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 53B0A174BD for ; Tue, 23 Jul 2019 15:25:07 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id q1LPhXbuW90onq1LPhQK1p; Tue, 23 Jul 2019 15:25:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YbjVJ+OGMaHIF5PocA2aj1Dp++vOeEBD3AxJbjBq3KQ=; b=L4aAcIlGiyKWmlCjKC226wYfCa G85x6PXdP0L3ZolBw7rY+immuA+hdV2rCnd9rDHyvYLJowSD2WH9BRFgkj1ugjdY+Kmp1sg2rywNY 9AICG45GgDilZAKWbI0DAYdvq; Received: from 97-122-178-82.hlrn.qwest.net ([97.122.178.82]:33244 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hq1LP-003nfX-2q; Tue, 23 Jul 2019 15:25:07 -0500 From: Tom Tromey To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] Add -P command line switch for executing Python scripts References: <20190721235427.21893-1-kevinb@redhat.com> <20190721235427.21893-3-kevinb@redhat.com> Date: Tue, 23 Jul 2019 20:25:00 -0000 In-Reply-To: <20190721235427.21893-3-kevinb@redhat.com> (Kevin Buettner's message of "Sun, 21 Jul 2019 16:54:26 -0700") Message-ID: <87sgqwv6ql.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-07/txt/msg00541.txt.bz2 >>>>> "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, Tom