This is the mail archive of the
mailing list for the GDB project.
Re: PATCH: gdb --args
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: PATCH: gdb --args
- From: Tom Tromey <tromey at redhat dot com>
- Date: 09 Nov 2001 19:52:17 -0700
- Cc: Eli Zaretskii <eliz at is dot elta dot co dot il>, gdb-patches at sources dot redhat dot com
- References: <firstname.lastname@example.org> <3BC5BB72.email@example.com> <9003-Thu11Oct2001185620firstname.lastname@example.org> <3BC5D5AE.email@example.com> <firstname.lastname@example.org> <3BC5DB7E.email@example.com> <firstname.lastname@example.org> <3BEB2D6A.email@example.com> <firstname.lastname@example.org> <3BEC46F7.email@example.com>
- Reply-To: tromey at redhat dot com
>>>>> "Andrew" == Andrew Cagney <firstname.lastname@example.org> 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?
>> 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 --
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
gdb --args foo "space in arg"
is invalid. If the user types `show args' he'll get an error with my
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