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

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

[Jan Kratochvil]

Hi,

[patch 2/2] [+doc] New -iex and -ix: -ex and -x before inferior load
http://sourceware.org/ml/gdb-patches/2012-02/msg00606.html

Before 7.5 gets branched/released I would like to yet change behavior of this
new feature.  The current order is:
 1. -iex and -ix
 2. /etc/gdbinit, ~/.gdbinit
 2. inferior load
 3. -ex and -x etc.

I would like to swap 1 <-> 2:
 1. /etc/gdbinit, ~/.gdbinit
 2. -iex and -ix
 2. inferior load
 3. -ex and -x etc.

In practice I found I need to override 'set auto-load safe-path ...' pre-set
by ~/.gdbinit for specific GDB runs by -iex.  There is no other way to do it.

Contrary to it I cannot imagine why one would want to get -iex commands
overriden by /etc/gdbinit and ~/.gdbinit.

I do not think this change can cause any negative change, only the positive
one.  Moreover the behavior of 7.4.50.* snapshots should not be too binding.

I chose the current FSF GDB HEAD behavior more randomly, if it is "init" then
it should be really the very first thing.  But that was wrong idea I think.

No regressions on {x86_64,x86_64-m32,i686}-fedorarawhide-linux-gnu.


Thanks,
Jan


gdb/
2012-06-16  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Execute -ix and -iex only after system and user gdbinit files.
	* main.c (captured_main): Move CMDARG_INIT_FILE and CMDARG_INIT_COMMAND
	processing down after gdbinit files.

gdb/doc/
2012-06-16  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.texinfo (File Options): Change -ix and -iex commands that apply
	only after gdbinit files.
	(Startup): Move -iex and -iex commands down after gdbinit files.

diff --git a/gdb/main.c b/gdb/main.c
index 3148d72..025bbe0 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -835,20 +835,6 @@ captured_main (void *data)
   quit_pre_print = error_pre_print;
   warning_pre_print = _("\nwarning: ");
 
-  /* Process '-ix' and '-iex' options early.  */
-  for (i = 0; VEC_iterate (cmdarg_s, cmdarg_vec, i, cmdarg_p); i++)
-    switch (cmdarg_p->type)
-    {
-      case CMDARG_INIT_FILE:
-        catch_command_errors (source_script, cmdarg_p->string,
-			      !batch_flag, RETURN_MASK_ALL);
-	break;
-      case CMDARG_INIT_COMMAND:
-        catch_command_errors (execute_command, cmdarg_p->string,
-			      !batch_flag, RETURN_MASK_ALL);
-	break;
-    }
-
   /* Read and execute the system-wide gdbinit file, if it exists.
      This is done *before* all the command line arguments are
      processed; it sets global parameters, which are independent of
@@ -864,6 +850,20 @@ captured_main (void *data)
   if (home_gdbinit && !inhibit_gdbinit)
     catch_command_errors (source_script, home_gdbinit, 0, RETURN_MASK_ALL);
 
+  /* Process '-ix' and '-iex' options early.  */
+  for (i = 0; VEC_iterate (cmdarg_s, cmdarg_vec, i, cmdarg_p); i++)
+    switch (cmdarg_p->type)
+    {
+      case CMDARG_INIT_FILE:
+        catch_command_errors (source_script, cmdarg_p->string,
+			      !batch_flag, RETURN_MASK_ALL);
+	break;
+      case CMDARG_INIT_COMMAND:
+        catch_command_errors (execute_command, cmdarg_p->string,
+			      !batch_flag, RETURN_MASK_ALL);
+	break;
+    }
+
   /* Now perform all the actions indicated by the arguments.  */
   if (cdarg != NULL)
     {
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a14e322..e0f8469 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -997,16 +997,16 @@ also be interleaved with @samp{-command} as required.
 @itemx -ix @var{file}
 @cindex @code{--init-command}
 @cindex @code{-ix}
-Execute commands from file @var{file} before loading gdbinit files or the
-inferior.
+Execute commands from file @var{file} before loading the inferior (but
+after loading gdbinit files).
 @xref{Startup}.
 
 @item -init-eval-command @var{command}
 @itemx -iex @var{command}
 @cindex @code{--init-eval-command}
 @cindex @code{-iex}
-Execute a single @value{GDBN} command before loading gdbinit files or the
-inferior.
+Execute a single @value{GDBN} command before loading the inferior (but
+after loading gdbinit files).
 @xref{Startup}.
 
 @item -directory @var{directory}
@@ -1261,14 +1261,6 @@ Here's the description of what @value{GDBN} does during session startup:
 Sets up the command interpreter as specified by the command line
 (@pxref{Mode Options, interpreter}).
 
-@anchor{Option -init-eval-command}
-@item
-Executes commands and command files specified by the @samp{-iex} and
-@samp{-ix} options in their specified order.  Usually you should use the
-@samp{-ex} and @samp{-x} options instead, but this way you can apply
-settings before @value{GDBN} init files get executed and before inferior
-gets loaded.
-
 @item
 @cindex init file
 Reads the system-wide @dfn{init file} (if @option{--with-system-gdbinit} was
@@ -1283,6 +1275,14 @@ DOS/Windows systems, the home directory is the one pointed to by the
 @code{HOME} environment variable.} and executes all the commands in
 that file.
 
+@anchor{Option -init-eval-command}
+@item
+Executes commands and command files specified by the @samp{-iex} and
+@samp{-ix} options in their specified order.  Usually you should use the
+@samp{-ex} and @samp{-x} options instead, but this way you can apply
+settings before @value{GDBN} init files get executed and before inferior
+gets loaded.
+
 @item
 Processes command line options and operands.
 

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

[Eli Zaretskii]

> Date: Sat, 16 Jun 2012 21:54:17 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> Before 7.5 gets branched/released I would like to yet change behavior of this
> new feature.  The current order is:
>  1. -iex and -ix
>  2. /etc/gdbinit, ~/.gdbinit
>  2. inferior load
>  3. -ex and -x etc.
> 
> I would like to swap 1 <-> 2:
>  1. /etc/gdbinit, ~/.gdbinit
>  2. -iex and -ix
>  2. inferior load
>  3. -ex and -x etc.

That would make it impossible to run a command before loading
.gdbinit, right?

> In practice I found I need to override 'set auto-load safe-path ...' pre-set
> by ~/.gdbinit for specific GDB runs by -iex.  There is no other way to do it.

We could invent some other way of doing that, but without taking away
what users can do now.

> Contrary to it I cannot imagine why one would want to get -iex commands
> overriden by /etc/gdbinit and ~/.gdbinit.

Not overriden by, _executed_before_.

> gdb/doc/
> 2012-06-16  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* gdb.texinfo (File Options): Change -ix and -iex commands that apply
> 	only after gdbinit files.
> 	(Startup): Move -iex and -iex commands down after gdbinit files.
> 
> diff --git a/gdb/main.c b/gdb/main.c
> index 3148d72..025bbe0 100644
> --- a/gdb/main.c
> +++ b/gdb/main.c
> @@ -835,20 +835,6 @@ captured_main (void *data)
>    quit_pre_print = error_pre_print;
>    warning_pre_print = _("\nwarning: ");
>  
> -  /* Process '-ix' and '-iex' options early.  */
> -  for (i = 0; VEC_iterate (cmdarg_s, cmdarg_vec, i, cmdarg_p); i++)
> -    switch (cmdarg_p->type)
> -    {
> -      case CMDARG_INIT_FILE:
> -        catch_command_errors (source_script, cmdarg_p->string,
> -			      !batch_flag, RETURN_MASK_ALL);
> -	break;
> -      case CMDARG_INIT_COMMAND:
> -        catch_command_errors (execute_command, cmdarg_p->string,
> -			      !batch_flag, RETURN_MASK_ALL);
> -	break;
> -    }
> -
>    /* Read and execute the system-wide gdbinit file, if it exists.
>       This is done *before* all the command line arguments are
>       processed; it sets global parameters, which are independent of
> @@ -864,6 +850,20 @@ captured_main (void *data)
>    if (home_gdbinit && !inhibit_gdbinit)
>      catch_command_errors (source_script, home_gdbinit, 0, RETURN_MASK_ALL);
>  
> +  /* Process '-ix' and '-iex' options early.  */
> +  for (i = 0; VEC_iterate (cmdarg_s, cmdarg_vec, i, cmdarg_p); i++)
> +    switch (cmdarg_p->type)
> +    {
> +      case CMDARG_INIT_FILE:
> +        catch_command_errors (source_script, cmdarg_p->string,
> +			      !batch_flag, RETURN_MASK_ALL);
> +	break;
> +      case CMDARG_INIT_COMMAND:
> +        catch_command_errors (execute_command, cmdarg_p->string,
> +			      !batch_flag, RETURN_MASK_ALL);
> +	break;
> +    }
> +
>    /* Now perform all the actions indicated by the arguments.  */
>    if (cdarg != NULL)
>      {
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index a14e322..e0f8469 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -997,16 +997,16 @@ also be interleaved with @samp{-command} as required.
>  @itemx -ix @var{file}
>  @cindex @code{--init-command}
>  @cindex @code{-ix}
> -Execute commands from file @var{file} before loading gdbinit files or the
> -inferior.
> +Execute commands from file @var{file} before loading the inferior (but
> +after loading gdbinit files).
>  @xref{Startup}.
>  
>  @item -init-eval-command @var{command}
>  @itemx -iex @var{command}
>  @cindex @code{--init-eval-command}
>  @cindex @code{-iex}
> -Execute a single @value{GDBN} command before loading gdbinit files or the
> -inferior.
> +Execute a single @value{GDBN} command before loading the inferior (but
> +after loading gdbinit files).
>  @xref{Startup}.
>  
>  @item -directory @var{directory}
> @@ -1261,14 +1261,6 @@ Here's the description of what @value{GDBN} does during session startup:
>  Sets up the command interpreter as specified by the command line
>  (@pxref{Mode Options, interpreter}).
>  
> -@anchor{Option -init-eval-command}
> -@item
> -Executes commands and command files specified by the @samp{-iex} and
> -@samp{-ix} options in their specified order.  Usually you should use the
> -@samp{-ex} and @samp{-x} options instead, but this way you can apply
> -settings before @value{GDBN} init files get executed and before inferior
> -gets loaded.
> -
>  @item
>  @cindex init file
>  Reads the system-wide @dfn{init file} (if @option{--with-system-gdbinit} was
> @@ -1283,6 +1275,14 @@ DOS/Windows systems, the home directory is the one pointed to by the
>  @code{HOME} environment variable.} and executes all the commands in
>  that file.
>  
> +@anchor{Option -init-eval-command}
> +@item
> +Executes commands and command files specified by the @samp{-iex} and
> +@samp{-ix} options in their specified order.  Usually you should use the
> +@samp{-ex} and @samp{-x} options instead, but this way you can apply
> +settings before @value{GDBN} init files get executed and before inferior
> +gets loaded.
> +
>  @item
>  Processes command line options and operands.

This is OK, Texinfo-wise.

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

[Jan Kratochvil]

On Sat, 16 Jun 2012 22:05:29 +0200, Eli Zaretskii wrote:
> > Date: Sat, 16 Jun 2012 21:54:17 +0200
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > 
> > Before 7.5 gets branched/released I would like to yet change behavior of this
> > new feature.  The current order is:
> >  1. -iex and -ix
> >  2. /etc/gdbinit, ~/.gdbinit
> >  2. inferior load
> >  3. -ex and -x etc.
> > 
> > I would like to swap 1 <-> 2:
> >  1. /etc/gdbinit, ~/.gdbinit
> >  2. -iex and -ix
> >  2. inferior load
> >  3. -ex and -x etc.
> 
> That would make it impossible to run a command before loading
> .gdbinit, right?

There is additionally:
4. load .gdbinit from the inferior's directory

If you are in directory ~ then the .gdbinit file is considered to be
~/.gdbinit (and not inferior .gdbinit).

Does it answer your question?  Do you see any problem with the new behavior.


> > In practice I found I need to override 'set auto-load safe-path ...' pre-set
> > by ~/.gdbinit for specific GDB runs by -iex.  There is no other way to do it.
> 
> We could invent some other way of doing that, but without taking away
> what users can do now.

I have not found a use case where the current behavior is better.


> > Contrary to it I cannot imagine why one would want to get -iex commands
> > overriden by /etc/gdbinit and ~/.gdbinit.
> 
> Not overriden by, _executed_before_.

I also agree with "executed before" but in practice it means that if distro
for example (Fedora does not) puts into /etc/gdbinit:
	set auto-load safe-path /opt:/distro-dir:/bin

Then there is no chance to use -iex 'set auto-load safe-path ...' currently.

(One can use add-auto-load-safe-path everywhere which would work, but then
still one cannot remove/reset directories.)


Thanks,
Jan

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

[Eli Zaretskii]

> Date: Sat, 16 Jun 2012 22:13:12 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> > > I would like to swap 1 <-> 2:
> > >  1. /etc/gdbinit, ~/.gdbinit
> > >  2. -iex and -ix
> > >  2. inferior load
> > >  3. -ex and -x etc.
> > 
> > That would make it impossible to run a command before loading
> > .gdbinit, right?
> 
> There is additionally:
> 4. load .gdbinit from the inferior's directory

My concern is about what happens before ~/.gdbinit is loaded, so
nothing that happens after that can resolve that.

> If you are in directory ~ then the .gdbinit file is considered to be
> ~/.gdbinit (and not inferior .gdbinit).
> 
> Does it answer your question?

No, see above.

> > > In practice I found I need to override 'set auto-load safe-path ...' pre-set
> > > by ~/.gdbinit for specific GDB runs by -iex.  There is no other way to do it.
> > 
> > We could invent some other way of doing that, but without taking away
> > what users can do now.
> 
> I have not found a use case where the current behavior is better.

It doesn't have to be better.  It has the advantage of being there
first.  It's the new behavior that must have a significant advantage
to justify an incompatible change of behavior.

> > > Contrary to it I cannot imagine why one would want to get -iex commands
> > > overriden by /etc/gdbinit and ~/.gdbinit.
> > 
> > Not overriden by, _executed_before_.
> 
> I also agree with "executed before" but in practice it means that if distro
> for example (Fedora does not) puts into /etc/gdbinit:
> 	set auto-load safe-path /opt:/distro-dir:/bin
> 
> Then there is no chance to use -iex 'set auto-load safe-path ...' currently.

But setting auto-load is not the only thing I can do with -iex.  I can
have any number of commands there which have nothing to do with
safe-path and stuff.

We are removing a potentially useful feature for reasons that were not
justified well enough.  Are there any reasons beyond the auto-load
issue?  If not, I submit the reasons are not grave enough for the
change, certainly not in a minor release.

And I don't see why we should pay so much attention to what Fedora
does in its GDB distribution.  For example, I always build my own GDB,
on any platform I work, and I don't see why I should be punished
because Fedora does something.

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

[Jan Kratochvil]

On Sat, 16 Jun 2012 23:14:15 +0200, Eli Zaretskii wrote:
> My concern is about what happens before ~/.gdbinit is loaded, so
> nothing that happens after that can resolve that.

I do not understand which command would you want to run before ~/.gdbinit.
Real world ~/.gdbinit should only change settings or define new commands.


> > I have not found a use case where the current behavior is better.
> 
> It doesn't have to be better.  It has the advantage of being there
> first.  It's the new behavior that must have a significant advantage
> to justify an incompatible change of behavior.

The idea is that this is not a "change" as 7.4 did not have -iex at all.
-iex/-ix is a new feature for 7.5 so I am trying to make it right before it
becomes a standard.


> But setting auto-load is not the only thing I can do with -iex.  I can
> have any number of commands there which have nothing to do with
> safe-path and stuff.

It can affect only commands/settings which have some influence on the loading
of inferior.  There are not so many of such settings.

Besides safe-path also "set debug-file-directory" and associated "set
sysroot", not sure which more commands, if any.

"set debug-file-directory" - if set in /etc/gdbinit or ~/.gdbinit - currently
also cannot be overriden by -iex.


> We are removing a potentially useful feature for reasons that were not
> justified well enough.  Are there any reasons beyond the auto-load
> issue?  If not, I submit the reasons are not grave enough for the
> change, certainly not in a minor release.

[again]
The idea is that this is not a "change" as 7.4 did not have -iex at all.
-iex/-ix is a new feature for 7.5 so I am trying to make it right before it
becomes a standard.

auto-load general acceptance looks to be bad so far so I try to improve its
user visible interface as best as I can.


> And I don't see why we should pay so much attention to what Fedora
> does in its GDB distribution.

This is unrelated to Fedora.  If I looked at Fedora then I can say that the
current -iex/-ix is already an established standard and it cannot be changed
anymore.  I do track FSF gdb-7.5 release for this change.


> For example, I always build my own GDB, on any platform I work, and I don't
> see why I should be punished because Fedora does something.

I really do not understand meaning of this paragraph.  I specifically care
about FSF GDB release at this moment where the change in some way may
negatively affect F17 users where the current behavior is already deployed.

Still I do not think this change can anyhow negatively affect -iex use.


Thanks,
Jan

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

[Eli Zaretskii]

> Date: Sat, 16 Jun 2012 23:31:49 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> On Sat, 16 Jun 2012 23:14:15 +0200, Eli Zaretskii wrote:
> > My concern is about what happens before ~/.gdbinit is loaded, so
> > nothing that happens after that can resolve that.
> 
> I do not understand which command would you want to run before ~/.gdbinit.
> Real world ~/.gdbinit should only change settings or define new commands.

GDB has a gazillion settings, so this still includes a lot of
possibilities.

> > > I have not found a use case where the current behavior is better.
> > 
> > It doesn't have to be better.  It has the advantage of being there
> > first.  It's the new behavior that must have a significant advantage
> > to justify an incompatible change of behavior.
> 
> The idea is that this is not a "change" as 7.4 did not have -iex at all.

That doesn't matter much nowadays, as people use development snapshots
all the time.

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

[Jan Kratochvil]

On Sun, 17 Jun 2012 04:52:28 +0200, Eli Zaretskii wrote:
> > I do not understand which command would you want to run before ~/.gdbinit.
> > Real world ~/.gdbinit should only change settings or define new commands.
> 
> GDB has a gazillion settings, so this still includes a lot of
> possibilities.

All these settings you can perfectly change even by -ex, after inferior has
been loaded.


> That doesn't matter much nowadays, as people use development snapshots
> all the time.

(a) Development snapshot should not make future guarantees (while releases
    do), IMO.
(b) As stated before I do not see when anything can break.  Things can just
    get working.


Regards,
Jan

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

[Joel Brobecker]

> Contrary to it I cannot imagine why one would want to get -iex commands
> overriden by /etc/gdbinit and ~/.gdbinit.

FWIW: Neither do I. Generally speaking, I always expect command-line
switches to override "configuration file settings". I was appalled
when I noticed that this is not the case for autossh, for instance.

-- 
Joel

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

[Doug Evans]

On Sat, Jun 16, 2012 at 2:31 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 16 Jun 2012 23:14:15 +0200, Eli Zaretskii wrote:
>> My concern is about what happens before ~/.gdbinit is loaded, so
>> nothing that happens after that can resolve that.
>
> I do not understand which command would you want to run before ~/.gdbinit.
> Real world ~/.gdbinit should only change settings or define new commands.
>
>
>> > I have not found a use case where the current behavior is better.
>>
>> It doesn't have to be better.  It has the advantage of being there
>> first.  It's the new behavior that must have a significant advantage
>> to justify an incompatible change of behavior.
>
> The idea is that this is not a "change" as 7.4 did not have -iex at all.
> -iex/-ix is a new feature for 7.5 so I am trying to make it right before it
> becomes a standard.

I'm not sure I have an opinion on the order of -iex vs ~/.gdbinit (etc.).
I do believe, however, that we need to have the freedom to change
features introduced after the previous release and before the next if
we have reason to believe we got it wrong.
[IOW, the fact that we're changing behaviour here is less important to
deciding what behaviour we want.]

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

[Jan Kratochvil]

Hi Eli,

are you still against this patch to reach gdb-7.5 before it gets branched?

re-stating the feature was not present at all in gdb-7.4 so it is no "change".


Thanks,
Jan

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

[Eli Zaretskii]

> Date: Wed, 20 Jun 2012 21:01:24 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> 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?

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

[Jan Kratochvil]

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

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

[Eli Zaretskii]

> Date: Fri, 22 Jun 2012 09:51:13 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> > 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.

A simple scenario where this could be useful is when either of these
two files does something conditioned on some variable's value.  Then
setting that variable before these are loaded can control what loading
them does.

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

[Jan Kratochvil]

On Fri, 22 Jun 2012 11:44:08 +0200, Eli Zaretskii wrote:
> A simple scenario where this could be useful is when either of these
> two files does something conditioned on some variable's value.  Then
> setting that variable before these are loaded can control what loading
> them does.

This is a case explicitly depending on the feature A which was not present in
gdb-7.4.

There exist other possibilities how to achieve the same, such as
'-ix /etc/gdbinit2' or /etc/gdbinit defining macro R and macro S and then
using -iex R or -iex S.

I do not consider this example as worth introducing new command.


Thanks,
Jan

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

[Eli Zaretskii]

> Date: Fri, 22 Jun 2012 13:32:07 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> On Fri, 22 Jun 2012 11:44:08 +0200, Eli Zaretskii wrote:
> > A simple scenario where this could be useful is when either of these
> > two files does something conditioned on some variable's value.  Then
> > setting that variable before these are loaded can control what loading
> > them does.
> 
> This is a case explicitly depending on the feature A which was not present in
> gdb-7.4.

But it is present now.  And it's a good thing.

> I do not consider this example as worth introducing new command.

That figures; but then you are not really objective in this matter.

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

[Jan Kratochvil]

On Fri, 22 Jun 2012 15:26:29 +0200, Eli Zaretskii wrote:
> > This is a case explicitly depending on the feature A which was not present in
> > gdb-7.4.
> 
> But it is present now.  And it's a good thing.
> 
> > I do not consider this example as worth introducing new command.
> 
> That figures; but then you are not really objective in this matter.

I believe nobody is going to use the feature A.  While I believe the feature B
would used here and there (at least by myself).  This is sure only my personal
opinion, no data for it.


Thanks,
Jan

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

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> That would make it impossible to run a command before loading
Eli> .gdbinit, right?

No:

gdb -nx -iex 'source ~/.gdbinit' -iex whatever

Tom

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

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> I would like to swap 1 <-> 2:
Jan>  1. /etc/gdbinit, ~/.gdbinit
Jan>  2. -iex and -ix
Jan>  2. inferior load
Jan>  3. -ex and -x etc.

It seems reasonable to me.

Tom

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

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> That doesn't matter much nowadays, as people use development snapshots
Eli> all the time.

I don't think this makes sense as a standard.
People using development snapshots ought to understand that they are
just that -- snapshots of development.

Tom

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

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> That figures; but then you are not really objective in this matter.

No need to get personal about it.

Tom

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

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
> Date: Fri, 22 Jun 2012 08:18:55 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> That figures; but then you are not really objective in this matter.
> 
> No need to get personal about it.

You make it sound like I said something improper.  I didn't.

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

[Joel Brobecker]

> Jan> I would like to swap 1 <-> 2:
> Jan>  1. /etc/gdbinit, ~/.gdbinit
> Jan>  2. -iex and -ix
> Jan>  2. inferior load
> Jan>  3. -ex and -x etc.
> 
> It seems reasonable to me.

Me too.

-- 
Joel

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

[Jan Kratochvil]

On Fri, 22 Jun 2012 15:26:29 +0200, Eli Zaretskii wrote:
> > This is a case explicitly depending on the feature A which was not present in
> > gdb-7.4.
> 
> But it is present now.  And it's a good thing.

As it is a snapshot it has been concluded it does not matter.

The feature A can be still added in the future.  The first public release of
the feature will be the feature B as feature B is more useful than feature A.

Checked it in:
	http://sourceware.org/ml/gdb-cvs/2012-07/msg00009.html


Thanks,
Jan