Re: [patch] New set auto-load-local-gdbinit + disable it by default

[Doug Evans <dje@google.com>]

On Tue, Jan 17, 2012 at 8:56 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 17 Jan 2012 17:44:32 +0100, Doug Evans wrote:
>> <bite> ???  I don't understand.
>
> I was exaggerating the "(top-gdb)" & co. to be "destructive" but I feel it 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.  For 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".  S/he might see it and
>> not even know that it trumps his/her own Makefile.
>
> GNUmakefile vs. Makefile... OK.  But 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 tarballs
> - supplied by customers.  Now I have to use secured VM for it after Python 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?