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

Jan Kratochvil
2012-01-18T19:19:28Z

On Wed, 18 Jan 2012 04:59:27 +0100, Joel Brobecker wrote:
> I would like to propose the following, however, to help the users
> who want to continue relying on it. I am happy to implement it
> if necessary:
>
> Provide a new command that would read the .gdbinit file in
> the current working directory if present, and do nothing
> otherwise. I would like to provide options that select
> between loading silently, and loading with a warning first,
> and why not, asking before loading.
>
> The idea is that the user who would like to preserve
> the old behavior can put that command in his $HOME/.gdbinit
> file.

The goal was you can do either
echo 'set auto-load-local-gdbinit on' >>~/.gdbinit
or
echo 'set auto-load-local-gdbinit on' >>/etc/gdbinit
and you get the former behavior.

Did you still prefer the command you propose?

> . To me, it is extremely important that system-gdbinit is still
> automatically loaded.

This patch/discussion affect neither /etc/gdbinit nor ~/.gdbinit in any way.

> It should be considered as trusted,

Yes, they are.

> . About the auto-loading of Python code: I think that the cost
> of removing the auto-loading, even if it is only for non-trusted
> directories, would be too high. I would prefer if it discussed
> this separately after the .gdbinit issue has been resolved.

After the discussion my current plan is:
* change .gdbinit to PROGRAM-gdb.rc (like -gdb.py),
rename FSF GDB src/gdb/.gdbinit to src/gdb/gdb-gdb.rc,
delete FSF GDB src/testsuite/.gdbinit ("set height 400" only, why?)
This will fix the annoying problems of running gdb for other programs in
the src/gdb/ directory.
* deprecate .gdbinit
* propose less intrusive gdb-gdb.rc, this sure affects only GDB developers,
like do not change the outer prompt to "(top-gdb)"; I do not mind much.
* in a second patch series deal with security, propose some "-safe" option,
PROGRAM-gdb.rc is more visible than .gdbinit, it has the same security
issue like PROGRAM-gdb.py and we have to deal with -gdb.py already anyway.

Thanks,
Jan