public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Per Bothner <per@bothner.com>
Cc: gdb@sources.redhat.com
Subject: Re: Harvard proposal
Date: Mon, 26 Feb 2001 10:13:00 -0000	[thread overview]
Message-ID: <3A9A9C2D.B6C9FA96@cygnus.com> (raw)
In-Reply-To: <m2vgpx2xg4.fsf@kelso.bothner.com>

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

  reply	other threads:[~2001-02-26 10:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-10 12:19 Nick Duffek
2001-02-10 13:27 ` Per Bothner
2001-02-10 17:11   ` Nick Duffek
2001-02-23 17:25   ` Andrew Cagney
2001-02-23 20:27     ` Per Bothner
2001-02-26  8:34       ` Andrew Cagney
2001-02-26  8:49         ` Per Bothner
2001-02-26 10:13           ` Andrew Cagney [this message]
2001-02-13 13:22 ` Andrew Cagney
2001-02-13 13:35   ` Nick Duffek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A9A9C2D.B6C9FA96@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    --cc=per@bothner.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).