From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 350 invoked by alias); 17 Jan 2012 16:26:48 -0000 Received: (qmail 32749 invoked by uid 22791); 17 Jan 2012 16:26:45 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 16:26:28 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0HGQRZ4014061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 11:26:27 -0500 Received: from host2.jankratochvil.net (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0HGQNth024347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Jan 2012 11:26:26 -0500 Date: Tue, 17 Jan 2012 16:34:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [patch] New set auto-load-local-gdbinit + disable it by default Message-ID: <20120117162621.GA3883@host2.jankratochvil.net> References: <20120117095552.GA6141@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00601.txt.bz2 On Tue, 17 Jan 2012 17:11:19 +0100, Doug Evans wrote: > On Tue, Jan 17, 2012 at 1:55 AM, Jan Kratochvil > wrote: > > Besides security problems the automatic execution is even inconvenient: > >        $ gdb testsuite/gdb.base/return > >        [...] > >        Setting up the environment for debugging gdb. > >        Function "internal_error" not defined. > >        Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] > >        Function "info_command" not defined. > >        Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] > >        .gdbinit:8: Error in sourced command file: > >        Argument required (one or more breakpoint numbers). > >         - What had happened?  Oh, I forgot -nx again! > > This only affects gdb developers though. It affects also gcc, gas, emacs, former Frysk, ReactOS, there will be more malicious .gdbinit files; not listed non-intrusive .gdbinit files which only define some new commands. > 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. When one wants to debug gdb in gdb the file gdb/.gdbinit is really the most destructive as all its various commands succeed making the debugging session completely unusable. > 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 use system.gdbinit but I use home.gdbinit sharing the problem. > Well, there is make (and I'm sure others). E.g., > echo "default:; @echo Gotcha." > GNUmakefile && make > :-) I was even thinking about make but I do not find it as a valid case. The primary goal of `make' is to read local Makefile - therefore one cannot be surprised by it. The primary goal of GDB is to process its arguments. I would bet some GDB users do not know there exists anything like .gdbinit. > 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 ...). I sure followed "auto-load-scripts". I can change it (later). > 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. :-) I find it OK that way. Maybe there will be some general disagreement. I need to know this decision to choose the way fixing next security hole - "set auto-load-scripts" + libthread_db.so.1 as implemented by Google. So that the other security options/commands can assume it that way. Thanks, Jan