How a multi-arch target stop should work

[Andrew Cagney <ac131313 at cygnus dot com>]

Hello,

[[The notes below came out of face-to-face discussion with Elena
Zannoni, Michael Synder, David Smith and Keith Seitz and Fernando
Nasser.  They were held last week as part of the ongoing project to
multi-arch GDB.]]

I think of this as the fine print that was missing from my other posts
on multi-arch.

Up until now, in discussing multi-arch, I've been ignoring one problem -
how to structure GDB so that it can simply and efficiently handle
multiple ``threads''.  Each of those threads having a different
architecture.  What follows is a sketch of how I think it should work. 
If you examine the GDB source you'll find it kind of mostly half works
like this now (sort of).

One thing to watch out for is terminology.  GDB overloads terms like
thread and target.  I'll try to be consistent in what follows.

So, starting at the target and working up^D^Ddown (this is an e-mail,
not a white board):

	o	a target system is made up of a number
		of contexts.  Each context has target
		state.  Examples are threads, cpus, ...

	o	when something happens in the target
		system an event is passed on up^D^Ddown
		towards gdb. The event is (normally)
		associated with a context.  In addition
		to the event the additional context target
		state may also be provided.

		[[what happens if it isn't?  To bad?]]

	------------------

	o	GDB contains one or more interfaces/probes/...
		into that target system that detect these
		target system events.

		[[right now GDB just has target.[hc] and
		assumes a single interface into the target]]

	o	when a GDB-target interface receives an
		event (plus any context target state)
		it does the following:

		+	looks the context up in
			the context DB using a
			target context ID as a key
			[[-> struct context *]]

			This GDB context will already
			contain the previous debug state
			for this context.

			If the context is new, it would
			be created and added to the
			data base.

		+	fills the ``struct context *''
			using information obtained
			from the target using the
			GDB-target interface.

			- the event (a signal)

			- if available, any target
			  state information which
			  *MIGHT* include the current
			  architecture

		+	binds an interface access mechanism
			that provides access to the target
			context's state.

	o	that context is then passed on up
		the GDB chain eventually reaching
		WFI (wait for inferior).

		WFI analyses the contexts target and
		debug states and determines what to
		do next.

		WFI might determine that it needs
		more information - a ``PC'', a
		``FRAME HANDLE'' - and would request
		that from the contexts GDB-target interface
		before returning.

		WFI might determine that the context
		should be continued and post a request
		to do that.

		WFI might determine that the target
		context should stop and return control
		to the CLI/GUI.

	o	If WFI determines that the target has
		stopped, it will go on to create
		a full ``struct frame_info *''.

		That object abstracting the target
		contexts stack state.

		Per other discussion, GDB would then
		use the ``struct frame_info *'' when
		displaying further information.

So how does this compare to current reality?

	o	GDB does have a ``struct thread_info *''
		that roughly corresponds to a ``context''.

	o	That GDB object only contains debug state.

	o	GDB can have only one active context
		target state.  It is contained in
		global variables scattered throughout
		GDB.

		If the context is changed, that target
		state is dumped.

		The target state should be kept in the
		context object.

	o	Much of gdb's existing code spends its
		time (re)selecting the context and then
		applying an operation to it.

		It should look the context up and then
		apply operations to it directly.
		
	o	WFI is almost scary.  It works by
		copying context debug state to/from
		local data structures.

		WFI should access the contexts debug
		state directly.

	o	The GDB-target interface (target
		vector) is not bound to a context.
		It is singular and global.
		(I'm ignoring the target stack here)

	o	[kevin note :-)
		The context DB (thread.c) is a key (groan)
		data structure.  It contains contexts
		(struct thread_info *) and is indexed
		by several keys:

			- target context ID (PID/TID/...)
			- gdb context ID
			- name (but not yet!)

		My understanding is that the PID -> ???
		change is upgrading the target context ID
		key to something large enough to hold
		all known target IDs.

	o	GDB is really confused over frames and
		frame handles.  Check the e-mail archives
		for posts on this.  The context is simple.
		GDB's existing frame creation code is not :-(.

So sounds good in theory?  Comments?

Next is to figure out how to best sequence things so this and the rest
can actually be implemented... :-)

	enjoy,
		Andrew