interface VS target (or something else wrong with the target vector)

Andrew Cagney cagney@gnu.org
Sun Oct 19 17:53:00 GMT 2003


Hello,

(thinking out loud)

The way the target vector's stack is implemented has come up on a number 
of occasions (e.g., it hasn't been possible for target layers interact 
with each other).

What I don't know has come up explicitly is how GDB's target vector is 
really a combination of a "target" and an "interface".

Consider the command "(gdb) target remote".  The command and target 
vector are being required to simultaneously handle two operations:

	- connect to the remote "interface"
	- use that "interface" to attach to a "target"

An "interface" ("remote", "core", "exec" (ptrace and proc), ...) at its 
simplest provides methods that create a target stack.  Such methods 
include "attach", "run", ...

A target stack, consisting of a number of stratum, provide a model of 
the running program - a thread stratum abstracting posix threads, a 
process stratum abstracting the underlying lwps, a file stratum filling 
in the gaps left missing by the process stratum.

Commands such as: "target remote", "target core" "target exec" are 
really selecting an interface.  Its just that at present, that interface 
is squashed into the target :-(

The distinction, and its importance, becomes apparent looking at the 
details of something like "(gdb) attach".  The command call's the 
selected interface's "attach" method.  That method then, starting with a 
  new "process stratum", builds out the target stack.  Below are added 
new "file stratum" (one per object file?), and above are added "thread 
stratum". et.al.  If the "process stratum" can be used to identify a 
file (say via /proc or shlibs) then that information is used to 
construct the new "file stratum".  If not, any existing selected 
executable is used (but it is still a _new_ "file stratum").

Contrast this to the current code.  "(gdb) attach" starts with a 
pre-constructed target stack (containing process and file stratum) and 
then attempts to push and shove and replace the various members until it 
gets to the structure it needs.  For instance, the pre-constructed 
target stack will already contain a [wrong] "file stratum" (bound to the 
previously selected executable), that has to be pushed aside replaced 
with information found in the running process.

So?

Not sure how how to persue it.  However, recognizing the distinction 
does let us better evolve the code.  Oh, I suspect this is going to hurt ...

enjoy,
Andrew



More information about the Gdb mailing list