Re: PATCH: gdb --args

[Andrew Cagney <ac131313 at cygnus dot 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);
with 
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
> gdbarch.

enjoy,
Andrew