From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56962 invoked by alias); 22 Dec 2019 09:09:24 -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 56950 invoked by uid 89); 22 Dec 2019 09:09:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=difficulty, successive, symbolfile, symbol-file X-HELO: mailsec110.isp.belgacom.be Received: from mailsec110.isp.belgacom.be (HELO mailsec110.isp.belgacom.be) (195.238.20.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 Dec 2019 09:09:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1577005762; x=1608541762; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=SE/8isVVF/7v11/iCjOURGugbA8syVXmWUKi3V1u3S4=; b=gs8F9kbyAeqwR/CSFrtloC8CNvUbdF5EOshEq/PGXSAldndsbHEZ4fY2 u5xPaNicmKuPv98oCFbn/yRmBUuM5A==; IronPort-SDR: eK/HsFU8gI3p+1Qc+aK9APIjKMgdKILYwr0GGsOdDTFlfFWX6q7slL+0rh5tDNRpgjp3hkxNPA eurUzh1UBZG7yXkJJ3FrrHijnalhsoL/PaRRQhAPSTNxwdHBQp+pJ6YLpft8bqqR8UYUSpHadJ ff+Xivscpum7qnySvlh0X1IG/f1cjDLCb6Kp0GaC9kXF1W6Ob4vJJ71L21DoVS2CPzZqLxkXis mHGkS8d4/5ClXA9ahTwLF67UNUD3XPO9yw/QmxLcwe5p1lxb+rMDReZJuxJ/CaPEbTBk90eoCj U9o= Received: from 156.47-242-81.adsl-dyn.isp.belgacom.be (HELO md) ([81.242.47.156]) by relay.skynet.be with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 22 Dec 2019 10:09:19 +0100 Message-ID: <4981a2dea635ed762e5b5fa75c253f3e162d81ed.camel@skynet.be> Subject: Re: [RFA 3/3] Document 'set|show exec-file-mismatch (reload|warn|off)' From: Philippe Waroquiers To: Christian Biesinger Cc: gdb-patches Date: Sun, 22 Dec 2019 09:09:00 -0000 In-Reply-To: References: <20191221143632.15990-1-philippe.waroquiers@skynet.be> <20191221143632.15990-4-philippe.waroquiers@skynet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00952.txt.bz2 On Sat, 2019-12-21 at 21:46 -0500, Christian Biesinger via gdb-patches wrote: > On Sat, Dec 21, 2019, 09:37 Philippe Waroquiers < > philippe.waroquiers@skynet.be> wrote: > > > Mention in NEWS the new option and the set/show commands. > > > > Document in gdb.texinfo the new option and the set/show commands. > > > > When would someone set this to off, or even warn? I'm wondering is it makes > sense to add this setting vs always having the reload behavior? Effectively, I think that in a large majority of the cases, the reload behavior is the correct thing to do, which is why it is the default value. However, I have added the option for the following reasons: * There are today already several features to choose flexibly the exec-file and symbol-file (see GDB manual "18.1 Commands to Specify Files"). The new option allows to retain the flexible manual control, which I assume is needed for some use cases. * Also, the previous trial to fix this problem was based on the notion of "sticky" exec-file: if the exec-file was explicitly given by the user, then it was never changed automatically when attaching to another process having another exec-file. IMO, this was not the best approach, as GDB would still silently use the wrong file in some cases (such as typo in the PID, or successive attach/detach after having given a program file as GDB argument). But this fix trial also seems to indicate some desire to let the user choose (in unusual circumstances) to keep a specific exec file. Note that for reload and warn, the message given to the user explicitly mention the 'exec-file-mismatch' option, so that users that need some control are informed of the possibility. Once the function 'validate_exec_file' was implemented and called at the right places, implementing the option itself was not a big deal, apart of the difficulty of properly naming and documenting the values :). Thanks Philippe > > > > gdb/ChangeLog > > YYYY-MM-DD Philippe Waroquiers > > > > * NEWS: Mention the new option and the set/show commands. > > > > gdb/doc/ChangeLog > > YYYY-MM-DD Philippe Waroquiers > > > > * gdb.texinfo (Attach): Document the new option and the > > set/show commands. > > (Connecting): Reference the exec-file-mismatch option. > > --- > > gdb/NEWS | 12 ++++++++++++ > > gdb/doc/gdb.texinfo | 31 +++++++++++++++++++++++++++++++ > > 2 files changed, 43 insertions(+) > > > > diff --git a/gdb/NEWS b/gdb/NEWS > > index ee10914fd8..1a90862b0d 100644 > > --- a/gdb/NEWS > > +++ b/gdb/NEWS > > @@ -3,6 +3,18 @@ > > > > *** Changes since GDB 9 > > > > +* New commands > > + > > +set exec-file-mismatch -- Set exec-file-mismatch handling > > (reload|warn|off). > > +show exec-file-mismatch -- Show exec-file-mismatch handling > > (reload|warn|off). > > + Set or show the option 'exec-file-mismatch'. When GDB attaches to > > + a running program and can determine the running program, this new option > > + indicates how to handle a mismatch between the current exec-file and > > + the automatically detected file. > > + 'reload' is the default value: in case of mismatch, GDB will warn the > > user > > + and reload the automatically determined file after user confirmation. > > + > > + > > *** Changes in GDB 9 > > > > * 'thread-exited' event is now available in the annotations interface. > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > > index 4d25f755d7..a246ba0bf5 100644 > > --- a/gdb/doc/gdb.texinfo > > +++ b/gdb/doc/gdb.texinfo > > @@ -2904,6 +2904,31 @@ the program is not found) by using the source file > > search path > > the @code{file} command to load the program. @xref{Files, ,Commands to > > Specify Files}. > > > > +@anchor{set exec-file-mismatch} > > +If the debugger can determine the program running in the process > > +and this program does not match the current exec-file, the option > > +@code{exec-file-mismatch} specifies how to handle the mismatch. > > + > > +@table @code > > +@kindex exec-file-mismatch > > +@cindex set exec-file-mismatch > > +@item set exec-file-mismatch @samp{reload|warn|off} > > +In case of mismatch between the current exec-file and the automatically > > +determined exec-file of the PID the debugger is attaching to, > > +@samp{reload} indicates to give a warning to the user and reload > > +the automatically determined exec-file. The user will be asked to > > +confirm the loading of the automatically determined file. > > +With @samp{warn}, @value{GDBN} just gives a warning to the user to > > +signal the mismatch. @samp{off} indicates to not check for mismatch. > > +The default value is @samp{reload}. > > + > > + > > +@cindex show exec-file-mismatch > > +@item show exec-file-mismatch > > +Show the current value of @code{exec-file-mismatch}. > > + > > +@end table > > + > > The first thing @value{GDBN} does after arranging to debug the specified > > process is to stop it. You can examine and modify an attached process > > with all the @value{GDBN} commands that are ordinarily available when > > @@ -21780,6 +21805,12 @@ established. If you are using @code{gdbserver}, > > you may also invoke > > @code{gdbserver} using the @option{--attach} option > > (@pxref{Running gdbserver}). > > > > +Some remote targets allow @value{GDBN} to determine the program running > > +in the process the debugger is attaching to. In such a case, @value{GDBN} > > +uses the value of @code{exec-file-mismatch} to handle a possible mismatch > > +between the program running in the process and the current exec-file. > > +(@pxref{set exec-file-mismatch}). > > + > > @end table > > > > @anchor{Host and target files} > > -- > > 2.20.1 > > > >