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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 17 Jan 2012 19:29:04 +0100, Doug Evans wrote:
> > 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.
> 
> Which survey is that?  Is it online?

Unfortunately I do not know about any.  I was just guessing results of
a hypothetical survey.  Sorry for being unclear.


> [And I'm curious once they understand what's going on, what do they prefer.
> Every new thing involves a bit of a learning curve ...

If anything requires a needless learning curve it will be changed.


> I'd be curious to know what the long term cost/benefit is for these newbies
> in addition to just the short term ... Once they understand it, do they
> prefer it?]

They do not need to understand it.  They just already use and develop other
debuggers.


> Script it.

If you prefer it in FSF GDB as a script I am can code it that way.


> Too complicated how?

I find

(a) Extract first and second argument in shell, that will be several lines of
    code.
(b) exec gdb -nx -x /etc/gdbinit -x ~/.gdbinit -ex "set auto-load-scripts off" -ex "set libthread-db-search-path" -ex "file $file -ex "core-file $corefile" "$@"

as more complicated than

gdb -secure "$@"

Don't you?


> Write the script once and you're done.
> If we had a contrib-like directory we could even ship one with gdb.

I have to ship it anyway so either Fedora + Red Hat will have to fork again or
it needs to be shipped with gdb.  It is a normal task of developers to analyze
shipped crashes/binaries.


> Are we sure we want to claim to the user community -safe is, umm, safe?
> It seems like we're a fair ways from being ready to claim it, setting
> aside auto-loading.

If we are not ready for -safe then we should not.

I am aware of DWARF reading unhandled run-offs but that is AFAIK only DoS
category of exploit.

Are you aware of any new exploits?  This Python/libthread_db is CVE-2011-4355.


Thanks,
Jan