This is the mail archive of the
mailing list for the GDB project.
How a multi-arch target stop should work
- To: GDB Discussion <gdb at sources dot redhat dot com>
- Subject: How a multi-arch target stop should work
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 15 Mar 2001 03:27:25 -0500
[[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
I think of this as the fine print that was missing from my other posts
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
+ fills the ``struct context *''
using information obtained
from the target using the
- the event (a signal)
- if available, any target
state information which
*MIGHT* include the current
+ binds an interface access mechanism
that provides access to the target
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
WFI might determine that it needs
more information - a ``PC'', a
``FRAME HANDLE'' - and would request
that from the contexts GDB-target interface
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
If the context is changed, that target
state is dumped.
The target state should be kept in the
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
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... :-)