Re: What to call a thread/cpu/?

[Daniel Berlin <dberlin at redhat dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:

> Hello,
> 
> At present gdb has this thing called ``struct thread_info *''.  It
> *should* contains several key GDB data structures including:
> 
> 	o	debug state
> 
> 		What GDB things it is doing
> 		to the thread - is it being
> 		stepped
> 
> 	o	target state
> 
> 		registers, memory, all that suff

Just a note, this isn't necessarily correct.
Not all operating systems let you get at the thread registers all the
time. The thread must be stopped, not in the kernel, etc.

One of the largest problems I had getting GDB going on BeOS (which
uses threads for literally everything. The only single threaded apps
are ported posix apps. All graphical apps have at least 2 threads) was
that registers can only be gotten when the thread is stopped, because
it's not safe otherwise.

Same with setting registers. You can only set the registers when you
go to resume/step/etc the thread.

I ended up working completely around GDB's current model, playing
tricks to convince it everything was the way it wanted it. 

What you really want to do is replace target_ops with something like
a thread_ops, associate the architecture with the thread, and have a
target "manager" that just keeps track of 
what threads are arounds, and each of the thread_ops associated with
them. 

That way, each thread doesn't have to be the same hardware, language,
etc.

This is actually what I did in my C++ rewrite, and it seems to work
well.

Of course, I don't have multiple hardware cpu's that are different around to test it, but
it works for multithreaded programs just fine.

(Frames also just implement an abstracted API, so they don't even have
to be real. As long as they provide the right interface, we don't give
a damn how they go about their work. This lets it do things like use
DWARF2's frame info to provide a frame, etc, intermixed with frames that are "real",
without nary a care in the world)
--Dan