From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Per Bothner Cc: gdb@sources.redhat.com Subject: Re: Harvard proposal Date: Mon, 26 Feb 2001 10:13:00 -0000 Message-id: <3A9A9C2D.B6C9FA96@cygnus.com> References: <200102102025.f1AKPtS11061@rtl.cygnus.com> <3A970CE6.6B2D2F34@cygnus.com> <3A9A8527.87A85677@cygnus.com> X-SW-Source: 2001-02/msg00372.html 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