Re: [patch] -iex and -ix: Execute them _after_ gdbinits

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 20 Jun 2012 21:38:03 +0200, Eli Zaretskii wrote:
> > are you still against this patch to reach gdb-7.5 before it gets branched?
> 
> I don't remember seeing any arguments to the contrary.  If others
> disagree with me, I'd love to hear why.

> Specifically, why isn't it a
> good feature to be able to execute commands before loading .gdbinit?

I do not see how it could be useful, in such cases one can execute the
commands after loading /etc/gdbinit or ~/.gdbinit with the same effect.  If
you mean ./.gdbinit then this proposed patch (change A to B) does not change
anything in such scenarios.

A - execute -iex/-ix as is in FSF GDB HEAD
  - execute /etc/gdbinit and ~/.gdbinit
B - execute -iex/-ix as is proposed in this patch
  - load inferior
  - load current directory ./.gdbinit
C - execute -ex/-x as always have been in any previous GDB

It was found out we need (=it would be useful to) to have feature B - see the
examples X1 and X2 below.

Having A is nice but if it does the same as B (see example Z) then feature
A is just a burden of additional option/command/documentation.  I think that
if we already have B then we should remove A.  Therefore just rename A to B.

Example Y shows when B is useful and neither A or C can be used instead but it
really is a made up case which makes no sense in real world to me.  Unless
someone figures out a better example of the Y type than I could.


X1 - Example when B is useful and neither A nor C can be used instead:
/etc/gdbinit:set auto-load safe-path $debugdir:$datadir/auto-load:/opt
gdb -iex "add-auto-load-safe-path $PWD" ./emacs
without having B:
warning: File ".../emacs-23.2/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/opt".
 - Using A option -iex does not work, it gets overriden by /etc/gdbinit.
 - Using C option -ex  does not work, it is too late.
with having B:
".../emacs-23.2/src/.gdbinit" gets successfully executed.

X2 - Example when B is useful and neither A nor C can be used instead:
/etc/gdbinit:set debug-file-directory /usr/lib/debug
gdb -iex 'set debug-file-directory ~/lib/debug' ~/bin/inferior
without having B:
Reading symbols from /home/user/bin/inferior...(no debugging symbols found)...done.
 - Using A option -iex does not work, it gets overriden by /etc/gdbinit.
 - Using C option -ex  does not work, it is too late.
with having B:
Reading symbols from /home/user/bin/inferior/bin/inferior...Reading symbols from /home/user/lib/debug/bin/inferior.debug...done.done.

Y - Example when A is useful and neither B nor C can be used instead:
build/gdb/configure --with-separate-debug-dir=/wrong/path/to/debug
/etc/gdbinit or ~/.gdbinit:file /bin/bash
gdb -iex 'set debug-file-directory /usr/lib/debug'
with having A:
Reading symbols from /bin/bash...Reading symbols from /usr/lib/debug/bin/bash.debug...done.done.
 - Using B option -iex or C option -ex are both too late.
without having A:
Reading symbols from /bin/bash...(no debugging symbols found)...done.

X1 and X2 seem to be real world cases to me.  I have given Y as a proof such
case exists but loading inferior from /etc/gdbinit or ~/.gdbinit makes no
sense to me, it is not a real world scenario.  FYI loading inferior from
./.gdbinit is not the Y case:

Z - Example when both A and B work the same (C cannot be used):
/etc/gdbinit:set auto-load safe-path $debugdir:$datadir/auto-load:/opt
./.gdbinit:file ./emacs
with having either A or B:
gdb -iex "add-auto-load-safe-path $PWD" ./emacs
".../emacs-23.2/src/.gdbinit" gets successfully executed.
 - Using both A and B option -iex works the same.
without having either A or B (not discussed here, such GDB has never existed):
gdb -ex "add-auto-load-safe-path $PWD" ./emacs
warning: File ".../emacs-23.2/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/opt".
 - Using C option -ex would be too late.

Thanks for the discussion but I would like to fix it for the first public
release (7.5).


Thanks,
Jan