This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: PATCH: gdb --args
>>>>>> "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