This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: gdb --args


>>>>>> "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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]