This is the mail archive of the
gdb-patches@sources.redhat.com
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: Fri, 09 Nov 2001 16:13:27 -0500
- 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>
>>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>
>
>>> 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.
>
>
> Andrew> As they say, someonebody elses problem. You've met your
> Andrew> contractual obligations by transforming argv into a correctly
> Andrew> quoted string and then passed it to the target interface.
>
> I looked into this some more today. There is still a lot I don't
> understand.
>
> First, the gdbarch approach seems to require many more changes than
> the target vector approach. For instance, my understanding is that
> since i386 isn't multi-arch, I must introduce a new macro into each
> i386/tm-*.h file which knows how to handle arguments for that target.
> (Maybe I can find something like config/tm-linux.h to edit instead,
> but that means I must read and understand config/i386/*.h.) A generic
> default implementation won't work properly because argument quoting is
> OS-dependent.
Check corrina's recent patch to add in_function_epilogue_p(). It
included a default case that did what 99% of targets wanted. Here 99%
of targets would be everything except DJGPP and (possibly) cygwin.
The multi-arch framework is constructed such that both muli-arch and
non-multi-arch targets continue to work.
> Second, and more importantly, I still don't see how this approach can
> be the correct one. In digging I found a real example which I think
> can demonstrate the problem (or if not it at least shows yet another
> thing I don't understand and which I need to understand to update this
> patch).
>
> 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.
Sorry I'm lost here. buildargv() takes a string and both dequotes and
splits it. It is a very primative implementation of SH's argument
parser - it is trying to emulate the behavour the user sees when running
``powerpc-elf-run arg arg arg arg''. If the architecture fuction
correctly transforms argv into a string then buildargv() should manage
to transform it back into an argv list.
> So suppose I go ahead and put argument construction into the gdbarch.
> How will this new code take effect when the user uses `target sim'?
> Which gdbarch structure will I modify to handle the sim target? As
> far as I can tell remote-sim.c doesn't reference gdbarch at all right
> now.
I don't think the remote-sim target needs any changes (unless there
turns out to be a bug in buildargv()). Just as long as as run_command()
gets the current architecture to do the argv->string transformation all
is well.
enjoy,
Andrew