This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
interface VS target (or something else wrong with the target vector)
- From: Andrew Cagney <cagney at gnu dot org>
- To: gdb at sources dot redhat dot com
- Date: Sun, 19 Oct 2003 13:53:10 -0400
- Subject: interface VS target (or something else wrong with the target vector)
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