From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16616 invoked by alias); 18 Aug 2012 15:01:16 -0000 Received: (qmail 16605 invoked by uid 22791); 18 Aug 2012 15:01:15 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 18 Aug 2012 15:01:00 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M8Y00H00HKTVX00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Sat, 18 Aug 2012 18:00:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8Y00H41HPLW200@a-mtaout23.012.net.il>; Sat, 18 Aug 2012 18:00:58 +0300 (IDT) Date: Sat, 18 Aug 2012 15:01:00 -0000 From: Eli Zaretskii Subject: Re: GDB 7.5: Problems with the auto-load safe-path feature In-reply-to: <20120818132128.GA6431@host2.jankratochvil.net> To: Jan Kratochvil Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <838vdcgs7c.fsf@gnu.org> References: <83d32ogz3g.fsf@gnu.org> <20120818132128.GA6431@host2.jankratochvil.net> X-IsSubscribed: yes 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 X-SW-Source: 2012-08/txt/msg00508.txt.bz2 > Date: Sat, 18 Aug 2012 15:21:28 +0200 > From: Jan Kratochvil > Cc: gdb-patches@sourceware.org > > > First, on MS-Windows the file gdb/gdb-gdb.gdb is not loaded, because > > GDB wants it to be named gdb.exe-gdb.gdb. I think the .exe suffix > > should be ignored in this case, so I suggest the patch below. OK to > > commit? > > Should it be really host type macro? Isn't it more a bug gdb/gdb-gdb.gdb is > created instead of gdb/gdb.exe-gdb.gdb? Is something like this common for > other projects on MS-Windows? (If so how does it behave for UNIX-host > Windows-target cross-projects?) Just asking if you are already aware of it. Until now, we had .gdbinit files, which worked on Unix and Windows alike. Isn't it true that we now encourage migration from .gdbinit to FOO-gdb.gdb files? If so, the issue gets introduced now that didn't exist before. But even if .gdbinit files are to stay, and FOO-gdb.gdb are in addition to them, my point is still valid, IMO: this file might be coming with the source distribution, not being generated at build time. In that case, omitting the .exe suffix will allow the file to be used on any platform, not just on Unix. I think this is better. > > Next, I have trouble understanding how we are supposed to deal with > > this in, e.g., the Emacs distribution, which comes with a heavily > > customized .gdbinit file. There seems to be no way of telling GDB > > that this .gdbinit is safe, except (a) through command-line arguments, > > or (b) by adding settings to global or user-private init files. > > Yes, choose either (a) or (b). I choose add-auto-load-safe-path in ~/.gdbinit > myself (for my gdb src directory), TIMTOWTDI. But that is not backward-compatible to older GDB versions, is it? Here's what I get with GDB 7.4.1: D:\usr\eli/.gdbinit:1: Error in sourced command file: "on" or "off" expected. This is with ~/.gdbinit which says just this: set auto-load safe-path / That's why I asked about a backward-compatible way: it's not inconceivable that someone would have several GDB versions on the same machine. And GDB auto-loaded files distributed with other projects may wish to be compatible to several GDB versions. > > How can other projects allow seamless loading of their GDB init files, in > > a way that is compatible with previous GDB versions, and without requiring > > each user to hack their global/private GDB init files? > > That's the goal of the safe-path feature, so that there is really no way how > a malicious extracted directory can hijack user's GDB. I'd hope we could find a better balance between preventing malicious attacks and punishing legitimate uses. But I digress. > > Another problem is that the error message displayed when GDB rejects > > to auto-load a file, viz.: > > > > warning: File "D:\gnu\bzr\emacs\trunk\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > > > > leaves it to the user to find out where are those safe directories. > > The 'auto-load safe-path' is the key there, I expected this will guide the > user to use '(help)? (set|show) auto-load safe-path' commands. It did guide there. But that didn't help, either: (gdb) show auto-load safe-path List of directories from which it is safe to auto-load files is $debugdir:$datadir/auto-load. That's why I wanted to find out what is $debugdir, see below. > > (gdb) show data-directory > > GDB's data directory is "d:\usr\share\gdb". > > > > But for $debugdir, there's no "show debug-directory"; instead I need > > to do this: > > > > (gdb) show debug-file-directory > > The directory where separate debug symbols are searched for is "d:\usr\lib\debug". > > Both variables are well documented in the GDB Manual, you have reviewed it. There's nothing wrong with the manual. My problem was with discoverability of these variables's values from within GDB. When I was presented with an opaque $debugdir, I wanted to know how close that was to the source or build directory, thinking that perhaps this is some misconfiguration issue, or maybe even (gasp!) a bug specific to MS-Windows. How about if we show the variable values explicitly in the warning message, instead of using variables whose values cannot be easily displayed? > > and the description does not make me sure this is the right directory, > > since it does not mention anything about scripts. At the very least, > > we should fix the description to mention the scripts. > > Offtopic, see above. ??? How so? The full doc string of "auto-load safe-path" still doesn't mention scripts: (gdb) help set auto-load safe-path Set the list of directories from which it is safe to auto-load files. Various files loaded automatically for the 'set auto-load ...' options must be located in one of the directories listed by this option. Warning will be printed and file will not be used otherwise. Setting this parameter to an empty list resets it to its default value. Setting this parameter to '/' (without the quotes) allows any file for the 'set auto-load ...' options. Each directory can be also shell wildcard pattern; '*' does not match directory separator. This option is ignored for the kinds of files having 'set auto-load ... off'. This options has security implications for untrusted inferiors. > > (gdb) apropos director > > [...] > > info auto-load local-gdbinit -- Print whether current directory > > [...] > > set auto-load local-gdbinit -- Enable or disable auto-loading of > > [...] > > show auto-load local-gdbinit -- Show whether auto-loading > > > > These truncated descriptions are caused by using ".gdbinit" in the > > first line of the doc string. To fix this, we should either use "GDB > > init" instead of .gdbinit, or remove the code that stops on the first > > period or comma altogether. > > OK, thanks for the report, I do not use 'apropos'. > > The patch below will make this change, are you OK with it? Yes, thanks. > BTW sorry for this note but 7.5 had a long pre-release time to catch these > issues you are reporting. There's a limit to how many projects one can pretest, and still do something useful during the day (assuming GDB maintenance is not what you get your paycheck for). I'm heavily invested in Emacs, and am practically the only person who deals with Windows pretests of Make and Gawk. Since there are a couple of people who obviously track the GDB development on MS-Windows (they tend to report regressions on trunk within days of their introduction), I hoped any such issues in GDB will be caught by them, to say nothing of the people who use CVS versions on Unix, and should have seen these issues a long time ago. I'm open to ideas how to help make our pre-release testing better, but that must be a collective effort, it cannot be blamed on a single person, even if that person is me. E.g., perhaps we should require at least one positive success report on each supported platform, or at least on the more popular ones, before we announce the pre-release a success and go for the release.