[patch] New set auto-load-local-gdbinit + disable it by default
Jan Kratochvil
jan.kratochvil@redhat.com
Tue Jan 17 18:44:00 GMT 2012
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
More information about the Gdb-patches
mailing list