From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24105 invoked by alias); 17 Jan 2012 16:11:36 -0000 Received: (qmail 24094 invoked by uid 22791); 17 Jan 2012 16:11:33 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 16:11:20 +0000 Received: by vbbfa15 with SMTP id fa15so2099304vbb.0 for ; Tue, 17 Jan 2012 08:11:20 -0800 (PST) Received: by 10.52.90.71 with SMTP id bu7mr8665992vdb.63.1326816680009; Tue, 17 Jan 2012 08:11:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.90.71 with SMTP id bu7mr8665978vdb.63.1326816679923; Tue, 17 Jan 2012 08:11:19 -0800 (PST) Received: by 10.220.229.1 with HTTP; Tue, 17 Jan 2012 08:11:19 -0800 (PST) In-Reply-To: <20120117095552.GA6141@host2.jankratochvil.net> References: <20120117095552.GA6141@host2.jankratochvil.net> Date: Tue, 17 Jan 2012 16:15:00 -0000 Message-ID: Subject: Re: [patch] New set auto-load-local-gdbinit + disable it by default From: Doug Evans To: Jan Kratochvil Cc: gdb-patches@sourceware.org X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-01/txt/msg00598.txt.bz2 On Tue, Jan 17, 2012 at 1:55 AM, Jan Kratochvil wrote: > Besides security problems the automatic execution is even inconvenient: > =A0 =A0 =A0 =A0$ gdb testsuite/gdb.base/return > =A0 =A0 =A0 =A0[...] > =A0 =A0 =A0 =A0Setting up the environment for debugging gdb. > =A0 =A0 =A0 =A0Function "internal_error" not defined. > =A0 =A0 =A0 =A0Make breakpoint pending on future shared library load? (y = or [n]) [answered N; input not from terminal] > =A0 =A0 =A0 =A0Function "info_command" not defined. > =A0 =A0 =A0 =A0Make breakpoint pending on future shared library load? (y = or [n]) [answered N; input not from terminal] > =A0 =A0 =A0 =A0.gdbinit:8: Error in sourced command file: > =A0 =A0 =A0 =A0Argument required (one or more breakpoint numbers). > =A0 =A0 =A0 =A0 - What had happened? =A0Oh, I forgot -nx again! This only affects gdb developers though. Another way to go is to enhance gdb's .gdbinit to check for which binary is being debugged and only do those things when it's gdb (and if necessary enhance the scripting language to support such a check). Seems generally useful, we should add support for it anyway. One problem I have with -nx is that it also turns off system.gdbinit. I've sometimes wanted to turn off everything but system.gdbinit, without having to specify the path to system.gdbinit in -x. > I do not see a precedent for executing anything from current directory by > default. =A0. (current directory) is also not contained in $PATH at all. > bash also does not execute .bashrc in any current directory. > And "gdb -x ./.gdbinit" is a pretty simple way to do what one wants to do. Well, there is make (and I'm sure others). E.g., echo "default:; @echo Gotcha." > GNUmakefile && make :-) > From what I know still there may be a resistance to this change, Eli plea= se > save your work with doc reviewing only after the change has been approved. > > Still at least the setting should go in and then one can then have > "set auto-load-local-gdbinit off" at least in ~/.gdbinit. =A0 Anyway I wo= uld > file a FESCo (Fedora Engineering Steering Committee) ticket for such "off= " in > /etc/gdbinit at least in distro and IMHO it needs to get approved (but ma= ybe > not, it would be another fork from upstream). I don't mind "set auto-load-local-gdbinit", though "set auto-load local-gdbinit" feels better, I could do "show auto-load" and see all the auto-load settings (assuming we migrate "auto-load-scripts" to "auto-load scripts" - though I'm beginning to like plain "scripts" in the name less ...). If you want to default it to "off", I think I'd give several releases warning notice, e.g., at least a year, to give enough time to change our minds if the user community really doesn't want it. :-)