From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17754 invoked by alias); 17 Jan 2012 17:27:06 -0000 Received: (qmail 17745 invoked by uid 22791); 17 Jan 2012 17:27:03 -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 17:26:50 +0000 Received: by vbbfa15 with SMTP id fa15so2190540vbb.0 for ; Tue, 17 Jan 2012 09:26:49 -0800 (PST) Received: by 10.52.155.196 with SMTP id vy4mr2929369vdb.12.1326821209451; Tue, 17 Jan 2012 09:26:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.155.196 with SMTP id vy4mr2929360vdb.12.1326821209380; Tue, 17 Jan 2012 09:26:49 -0800 (PST) Received: by 10.220.229.1 with HTTP; Tue, 17 Jan 2012 09:26:49 -0800 (PST) In-Reply-To: <20120117165640.GB5344@host2.jankratochvil.net> References: <20120117095552.GA6141@host2.jankratochvil.net> <20120117162621.GA3883@host2.jankratochvil.net> <20120117165640.GB5344@host2.jankratochvil.net> Date: Tue, 17 Jan 2012 17:33: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/msg00607.txt.bz2 On Tue, Jan 17, 2012 at 8:56 AM, Jan Kratochvil wrote: > On Tue, 17 Jan 2012 17:44:32 +0100, Doug Evans wrote: >> ??? =A0I don't understand. > > I was exaggerating the "(top-gdb)" & co. to be "destructive" but I feel i= t so. > > >> I also don't understand the reference to making the debugging session >> completely unusable. > > Personally I always feared what is that "(top-gdb)" there and what new > breakpoints it created and why it prints complaints which are not printed > normally etc. etc., I just rather quit and and run normal GDB for GDB. I, OTOH, like the (top-gdb) prompt. When I'm switching back and forth between parent and child gdb, I like trivially knowing which one I'm in. I also like the automagic breakpoints on internal_error, and other stuff. > If I want some special environment (.gdbinit) for GDB-to-GDB I can study = the > supplied one and _then_ I can load the supplied one. =A0For a newbie it is > a needless burden to complicate the debugging of GDB even more. 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? >> The user will be surprised if s/he has been using "Makefile" and not >> noticing that someone slipped in "GNUmakefile". =A0S/he might see it and >> not even know that it trumps his/her own Makefile. > > GNUmakefile vs. Makefile... OK. =A0But running "make" in untrusted source > directory is never safe as Makefile itself is not trusted. > > While I occasionally do run "gdb -nx file core" on untrusted crash tarbal= ls > - supplied by customers. =A0Now I have to use secured VM for it after Pyt= hon and > libthread_db.so.1 automatic loading crept in. libthread_db has been auto-loaded for ages AFAIR - user's wanted threaded debugging to Just Work ... [insert discussion of removing the few remaining reasons for having libthread_db] There is the path that gdb searches for libthread_db, maybe you meant to refer to that; 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". 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?