Re: PATCH: gdb --args

[Andrew Cagney <ac131313 at cygnus dot com>]

>>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> 
> Andrew> Check corrina's recent patch to add in_function_epilogue_p().
> Andrew> It included a default case that did what 99% of targets
> Andrew> wanted.  Here 99% of targets would be everything except DJGPP
> Andrew> and (possibly) cygwin.
> 
> Many or most of the remote targets don't accept arguments at all.
> Maybe having a Unix-like default for these is ok though?

I don't think any do.  Of the simulators, not many of them do either. 
The PPC, with its ability to emulate a number of different UNIX like 
environments, is somewhat unique.

>>> If I'm reading the source correctly, right now with a PPC Linux gdb
>>> the user can use `target sim'.  This changes how the quoted argument
>>> will be decomposed -- instead of using sh-style dequoting, instead the
>>> `buildargv()' function from libiberty will be used.  But as far as I
>>> can tell, typing `target sim' doesn't change anything in the current
>>> gdbarch.  All it seems to change is the current target vector.
> 
> 
> Andrew> Sorry I'm lost here.  buildargv() takes a string and both
> Andrew> dequotes and splits it.  It is a very primative implementation
> Andrew> of SH's argument parser - it is trying to emulate the behavour
> Andrew> the user sees when running ``powerpc-elf-run arg arg arg
> Andrew> arg''.  If the architecture fuction correctly transforms argv
> Andrew> into a string then buildargv() should manage to transform it
> Andrew> back into an argv list.
> 
> buildargv() splits the string one way.  fork-child.c splits it a
> different way -- the /bin/sh way.  If STARTUP_WITH_SHELL is 0, then
> fork-child.c uses a completely different dequoting method --
> breakup_args().

That sounds like bugs in either fork-child.c or remote-sim.c.

> If the user changes the target with `target sim', then the dequoting
> rules change without any corresponding change to current_gdbarch.  So
> if the quoting method is in current_gdbarch, it will continue to use a
> fixed, and possibly inappropriate, quoting method.
> 
> Suppose for instance that STARTUP_WITH_SHELL is 0.  In this case
> spaces in command-line arguments are simply invalid.  So an invocation
> like:
> 
>     gdb --args foo "space in arg"
> 
> is invalid.  If the user types `show args' he'll get an error with my
> current patch.

If I understand what you're saying correctly:

	(gdb) set args "space in arg"
	(gdb) run

could have different behavour dependant on STARTUP_WITH_SHELL (notice 
that this is independant of your change).  GDB should provide a 
consistent user experience across UNIX platforms and configurations.  If 
GDB isn't doing this then that is a bug in GDB (in this case most likely 
in fork-child.c).

Looking at inferior.h, STARTUP_WITH_SHELL is hardwired to 1 so I don't 
expect anyone to ever notice this bug.

> However, if the user type `target sim' and then `show args', it ought
> to work.  But if the quoting function is in gdbarch, I don't see how
> it can.  `target sim' has no effect on current_gdbarch, as far as I
> can see.

It works because both fork-child and remote-sim are expected to exibit 
the same behavour.  Failing to this would be breaking their part of the 
contract.

Andrew