This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Next for GDB
Is today Scary Andrew Mail Day? 8-)
At Fri, 1 Aug 2003 23:47:12 +0000 (UTC), "Andrew Cagney" wrote:
[ ... ] My curent TODO list for gdb includes
[ ... ]
- the sim vector
What's on your to-do list there?
`all of the below'? See the sim category in the bug database.
If there's going to be much work on the interface to the simulator,
one thing that *should* be implemented IMO is some mechanism to allow
multiple processors in a simulator to be exposed to GDB, probably
using some thread-related mechanism.
yep.
both GDB's target vector, and the simulator vector need an upgrade.
I've not looked into GDB's thread bits for about a year and a half, i
don't recall if it splits the notion of 'user thread' vs. 'kernel
context' (i.e., M and N in MxN threading systems) or tries to make any
such distinction. Multiple cores would kind-of correspond to multiple
kernel contexts...
yep.
gdb currently isn't well structured enough to do this.
It's also related to getting GDB to handle backtraces through
interpreters. It could be done with further target layers, or perhaphs
frame layers...
For the moment, I'm just worred about making the architecture code
non-global.
i've got a year and a half old diff that starts adapting some old
version of GDB (5.2?) to support multiple cores/threads under
simulation, if somebody wants it.
(in order to support debugging multiple cores in our gdb+simulator --
again a plug for http://sibyte.broadcom.com/public/resources/#tools --
we currently use a fairly nasty but functional hack. I started to try
to fix that, but then that business trip ended and lack of
productivity resumed.)
Also `making a dead cat bounce'. Layering a simulator over the top of
another target so the simulator uses the target for registers and
memory. Would make possible:
- less intrusive inferior function calls (don't write the results back)
- executing code on dead targets
- simulated single stepping
this would involve a lot more work so ...
Andrew