This is the mail archive of the
mailing list for the GDB project.
Re: What to call a thread/cpu/?
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: What to call a thread/cpu/?
- From: Fernando Nasser <fnasser at redhat dot com>
- Date: Thu, 15 Mar 2001 10:20:02 -0500
- CC: GDB Discussion <gdb at sources dot redhat dot com>
- Organization: Red Hat Canada
- References: <3AB06775.EA0D0D60@cygnus.com>
Using "threads" for processors started as a hack and evolved to the
right thing (or is evolving). One day we should be able to handle
several different kinds of "threads": processors, kernel threads,
I suggest we add an attribute to the current "threads" (after renaming
it to something, lets say xcontext (for "execution context")):
enum xcontext_type possible values:
processor - a cpu in a multiprocessor
kthread - a kernel level thread
uthread - a user level thread
The distinction may be useful.
Andrew Cagney wrote:
> 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
> o target state
> registers, memory, all that suff
> (it doesn't but that is another story :-)
> The thing to realise is that GDB can be used to debug not only threads
> but also hardware CPUs. Given that, the term ``thread'' is starting to
> struggle and is showing signs of being very overloaded.
> The question is, what internal name should GDB use when refering to a
> thread/cpu/... or should it just stick to thread?
> I've seen suggested/used:
> You don't get to win a prise for comming up with the name but you do get
> the chance to be able to show GDB to your grand children and say ``hey I
> named that object'' :-)
Red Hat Canada Ltd. E-Mail: email@example.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9