Re: PATCH: gdb --args

[Andrew Cagney <ac131313@cygnus.com>]

>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> 
> Andrew> The target's operating system.  I think the target's operating
> Andrew> system is something independant of the actual interface
> Andrew> (ptrace, procfs, remote, ...) GDB uses to control the target
> Andrew> program.
> 
> Is there a target OS vector or something like that?
> I don't understand how the code would look if I made this change.

Yes.  Only thanks to a legacy of unfortunate name choices (target.[hc]) 
it is called gdbarch.

The code would look almost identical only instead of calling a 
target.[hc] method it would call an architecture method.

I'll resist the temptation of suggesting that ``register_read'' would 
make a good example - the x86 isn't multi-arch and wouldn't be able to 
use it :-/  Can I instead suggest something like target_read_pc.

--

I think most of the other changes are CLI and (a little) top.c related 
(even though the sit in infcmd.c).  I'll defer to other maintainers for 
comments on that.

	Andrew

PS: The below is for reference, and was part of a reply to an earlier 
e-mail.

 > As I understood it, to_create_inferior assumed that ARGS was properly
 > quoted for the target.  To me this implies that the transformation
 > from argv[] to string must be done in a target-dependent way -- that
 > is, in a way that matches what the corresponding to_create_inferior
 > expects.

GDB suffers from some really badly chosen terminology.  ``target'' is 
badly overloaded.

I wasn't exactly clear in what I ment by ``architecture (well OS)'', sorry.

The system being debugged will have:

- an interface to control the target being debugged
In GDB that is the target.[hc] jumbo object.
GDB uses this interface to perform operations such as step, continue, 
kill and start the system being debugged.  It might use ptrace, procfs, 
remote or nothing (core).

- an interface describing the systems ISA, ABI and OS
In GDB that is the gdbarch.[hc] jumbo object.
GDB calls on the gdbarch object when doing things that are dependant on 
the target architecture rather than the details of the target interface. 
  For instance, shared library support, an OS feature, is managed by 
gdbarch and not the target vector.

I think what you're doing is independant of the control interface 
(target.[hc]) but is target operating system dependant.  Hence 
suggesting that it live in gdbarch.