This is the mail archive of the
gdb-patches@sources.redhat.com
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: <87ofnfm80i.fsf@creche.redhat.com> <3BC5BB72.9040300@cygnus.com> <9003-Thu11Oct2001185620+0200-eliz@is.elta.co.il> <3BC5D5AE.1020106@cygnus.com> <87g08qxeb4.fsf@creche.redhat.com> <3BC5DB7E.3000908@cygnus.com> <87g07o6bdf.fsf@creche.redhat.com> <3BEB2D6A.5000500@cygnus.com> <87eln7irg3.fsf@creche.redhat.com> <3BEC46F7.4070601@cygnus.com>
- Reply-To: tromey at redhat 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?
>> 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().
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.
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.
Tom