From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OH5WDJixfl90XwAAWB0awg (envelope-from ) for ; Thu, 08 Oct 2020 02:28:40 -0400 Received: by simark.ca (Postfix, from userid 112) id 3088C1EF6F; Thu, 8 Oct 2020 02:28:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 43A061E58C for ; Thu, 8 Oct 2020 02:28:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A51AD3892454; Thu, 8 Oct 2020 06:28:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A51AD3892454 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1602138517; bh=4OyZE1QyRahLYQk4tkSKClyK+9CFSIhz7WP2xMAe3m8=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=pxTcnCuoim45XwmnpbZgVoF/nNVVKDWDP1ANJJ8rHf4amc1j01JWWsOt7nVXimbVv wCI5ezKFERGj/5yo90mxoDA7XVnqVCzFpYUflV/PPNbfmGbHXqI8Fy0+9TTAVdpzjq QCy6O6zdiWAFriKscm2EPEg0mZy+OzsZfqZMejZE= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 0EE10385E038 for ; Thu, 8 Oct 2020 06:28:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0EE10385E038 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59258) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kQPPn-0006qn-EJ; Thu, 08 Oct 2020 02:28:35 -0400 Received: from [176.228.60.248] (port=1804 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kQPPm-0003vg-7r; Thu, 08 Oct 2020 02:28:34 -0400 Date: Thu, 08 Oct 2020 09:28:41 +0300 Message-Id: <83k0w18c4m.fsf@gnu.org> To: Andrew Burgess In-Reply-To: (message from Andrew Burgess on Wed, 7 Oct 2020 21:05:08 +0100) Subject: Re: [PATCH 4/7] gdb: process startup files and startup command line options References: X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: tom@tromey.com, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" > From: Andrew Burgess > Date: Wed, 7 Oct 2020 21:05:08 +0100 > Cc: Tom Tromey > > Adds the ability to process commands at a new phase during GDB's > startup. This phase is earlier than the current initialisation file > processing, before GDB has produced any output. Thanks. Some comments about the documentation parts below. > diff --git a/gdb/NEWS b/gdb/NEWS > index c64dda7bbcb..bd3aca84d51 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -21,6 +21,17 @@ > $HOME/.gdbinit. On Apple hosts the search order is instead: > $HOME/Library/Preferences/gdb/gdbinit, $HOME/.gdbinit. > > +* GDB will now load and process commands from > + ~/.config/gdb/gdbstartup, ~/.gdbstartup, or a local file > + ./.gdbstartup if these files are present. These files are processed > + earlier than any of the previous initialization files and can effect ^^^^^^ "affect" > + parts of GDB's startup that previously had already been completed > + before the initialization files were read. This begs the question: such as?... Can we at least say something about that here? > +* GDB now has two new options "--startup-command" and > + "--startup-eval-command" with corresponding short options "-sx" and > + "-sex" that allow startup options to be passed on the command line. What are "startup options" for this matter? Perhaps an example will be enough to explain that. > +@item > +@cindex startup file > +Reads startup options from the startup file (if any) in your home > +directory, followed by any startup options contained in a startup file > +(if any) in the local directory as long as @samp{set auto-load > +local-gdbinit} is set to @samp{on} (@pxref{Init File in the Current > +Directory}), @pxref{Local directory startup file}. > + > +@item > +Any startup command line options (@samp{startup-command} and > +@samp{startup-eval-command}) are processed. The previous @item uses the style of others in the list ("Reads ..."), but this item suddenly switches to a different style. Suggest to reword: Processes any startup command-line options ... > +The files processed are split into two categories @dfn{startup files} > +and @dfn{initialization files}. The startup files are loaded as > +early as possible during @value{GDBN}'s startup and allow a limited > +set of settings to be configured that can affect how the rest of > +@value{GDBN} starts up. The more general initialization files are > +processed later after @value{GDBN} has finished its own internal > +startup process, any commands can be used in these files. This again leaves unexplained the practical difference between these two classes. I as a reader am left wondering what kind of commands and settings would I need to put in the startup files, and why. Please add some text that explains this, preferably with a couple of examples. > +On non-Apple hosts the locations searched are: > +@table @file > +@item $XDG_CONFIG_HOME/gdb/gdbstartup > +@item $HOME/.config/gdb/gdbstartup > +@item $HOME/.gdbstartup > +@end table This should be @itemize, not @table. Also, I wonder whether it is wise to use the $FOO notation here, as that is a Posix shell-ism. How about something like this instead: @item The @file{gdb/gdbstartup} subdirectory of the directory pointed to by the environment variable @env{XDG_CONFIG_HOME}, if it is defined. > +While on Apple hosts the locations searched are: > +@table @file > +@item $HOME/Library/Preferences/gdb/gdbstartup > +@item $HOME/.gdbstartup > +@end table I wonder why we make special case for Apple system, but not for MS-Windows (which also has its own conventions for user-private settings directories). > +@anchor{Local directory startup file} > +@subsubsection Local directory startup file Instead of @anchor, how about using @node (here and elsewhere)? > +@value{GDBN} will check the current directory for a file called > +@file{./.gdbstartup}. I think the "./" part is redundant here, you already say that the file is looked up in the current directory.