This is the mail archive of the
mailing list for the GDB project.
Re: PATCH: gdb --args
- To: tromey at redhat dot com
- Subject: Re: PATCH: gdb --args
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 08 Nov 2001 20:12:10 -0500
- Cc: Eli Zaretskii <eliz at is dot elta dot co dot il>,gdb-patches at sources dot redhat dot com
- References: <email@example.com> <3BC5BB72.firstname.lastname@example.org> <9003-Thu11Oct2001185620email@example.com> <3BC5D5AE.firstname.lastname@example.org> <email@example.com> <3BC5DB7E.firstname.lastname@example.org> <email@example.com>
> My question is: is it really the case that argument quoting is
> independent of the control interface?
> My concern here is that if quoting (the --args code) and dequoting
> (the fork-an-inferior code) are handled separately, they could
> conceivably become out of sync.
> I don't know of examples where this could happen, but then, I don't
> know gdb all that well either. (And I especially can't predict the
> future, which is where some possible problem may lie [:-)]
> I can make up what I think is a plausible example though. Suppose
> someone invents a new way to start a Unix inferior. Say, some server
> which knows how to launch and debug ordinary Unix processes and which
> talks to gdb via a socket.
For instance, replace something like:
exec ("/bin/sh", "-c", program_and_args);
exec (program, args, ...);
> Now, if whoever writes this decides to use a different quoting scheme
> than the current gdb, trouble will result -- gdb will quote arguments
> using the Unix convention (the ISA, ABI and OS will be identical to
> the native platform), but the control interface will expect them to be
> quoted using the new server's convention.
As they say, someonebody elses problem. You've met your contractual
obligations by transforming argv into a correctly quoted string and then
passed it to the target interface.
If someone wants to do radical surgery on a target (such as that change
above) then it is that persons responsibility to ensure that their code
can dequote an argument string transforming it into the format they
require. This requirement is even independant of your change - if this
wasn't done, people using the existing `set args'' mechanism would very
quickly notice that something was very very wrong.
The only alternative I can see to this is to make both the string (from
set args) and argv vector parameters to the target method. That way,
the final target can decide what to do. I don't think it is a good move
however since it means modifying every target rather than just geting
the argv transformed into a string. I think you've already (wisely)
discarded this option.
> That's just one example. There are probably other ways these things
> can get out of sync.
> Maybe this is an impossible scenario. I don't know. I just want to
> make sure that separating these two things won't result in some sort
> of gdbarch/target disagreement at some future date. I'd prefer to
> understand this point before I rewrite the --args patch to use