From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15661 invoked by alias); 17 Jan 2012 17:49:02 -0000 Received: (qmail 15653 invoked by uid 22791); 17 Jan 2012 17:49:01 -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 17:48:47 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0HHmjUT002647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 12:48:45 -0500 Received: from host2.jankratochvil.net (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0HHmecq027847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Jan 2012 12:48:43 -0500 Date: Tue, 17 Jan 2012 17:55: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: <20120117174839.GA8459@host2.jankratochvil.net> References: <20120117095552.GA6141@host2.jankratochvil.net> <20120117162621.GA3883@host2.jankratochvil.net> <20120117165640.GB5344@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00609.txt.bz2 On Tue, 17 Jan 2012 18:26:49 +0100, Doug Evans wrote: > I, OTOH, like the (top-gdb) prompt. I think you and me can very easily do whatever we like with GDB. I care more about both newbie users of GDB and also about newcomers to GDB development. > One could argue the converse too ... Having to manually request > whatever goodies the developers find useful adds a needless burden. > Why can't gdb just auto-adjust itself for debugging the program at > hand? Because it is then different than normal GDB. It is difficult to argue myself but IMO in a survey between GDB newbies they find easier if GDB behaves always the same than if it behaves differently according to which program you load into it. > There is the path that gdb searches for libthread_db, maybe you meant > to refer to that; Yes, I meant this part. > one can change it before choosing the file to debug. You seem to > suggest that -nx was "good enough" before. If that was good enough > before (and that's a big "if"), why is changing the search path first > not also "good enough". Now instead of just -nx one has to use also "set auto-load-scripts off", use -ex "file X" and -ex "core-file Y" instead of just X and Y to get that "set auto-load-scripts off" executed first, use beforehand -ex "set libthread-db-search-path /foo", OK, that may be enough if I did not miss anything else. I admit I did not know about "set auto-load-scripts off" myself until recently. > As for Python auto-loading, if -nx was good enough before (and if one > *really* wanted to run gdb in a security hardened environment one > would use a secured VM or some such anyway ...), then why isn't > turning off auto-loading of Python scripts ahead of time also good > enough? Yes, it is, it is just too complicated, similiar to the extra VM. I plan to just merge the paragraph above into some user-accessible command-line option "-safe". I am just not sure how to load pretty printers from system libraries which are safe but which do not get loaded after "set auto-load-scripts off". Thanks, Jan