This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Harvard proposal
Per Bothner wrote:
(wonder what adta stands for)
> > GDB currently doesn't understand the concept of multiple, separate
> > addresses spaces (as would be seen when debugging two separate UNIX
> > processes).
>
> I know. I thought that was what we trying to define, how Gdb *should*
> handle the concept of multiple, separate addresses spaces.
Hmm, I think the problem is that ``separate address space'' is pretty
loosely defined.
Chorus (an OS) has a grouping thing called an actor. An actor contains
a number of address spaces (or address translations) - text, data, io,
... An actor also contains a number of threads. Given that all threads
live within an actor they all interpret addresses according to that
actors address translations/spaces. All the threads within an actor see
the world through the same set of eyes.
A Chorus systeme also contains multiple actors.
I think people may be trying to solve what I would consider to be two
separate problems:
1. handling separate text, data and io
spaces visible to the threads within
a single actor.
2. handling multiple actors
Or to put it another way, the possibility
that two threads have two very different
views of the world.
GDB can handle the debugging of an actor provided it only contains one
address space (unified text and data). It can kind of handle separate
text and data and totally fails to handle I/O. GDB can't handle
multiple actors.
I think this discussion should should be focusing on ``1.''.
Just keep in mind things like ``space:address'' eventually becomming
context sensative (dependant on the current thread/actor) and the
possible need to expand things further to include
``actor::space:address'' say.
enjoy,
Andrew