This is the mail archive of the gdb@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]
Other format: [Raw text]

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


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