From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
Date: Wed, 03 Oct 2001 14:38:00 -0000
Message-id: <3BBB8547.2030403@cygnus.com>
References: <3BB4D843.A92818B9@cygnus.com> <3BB4E273.5020308@cygnus.com> <3BBB4D90.AE2B5AEE@cygnus.com> <20011003140639.A661@nevyn.them.org> <3BBB54C6.5392258C@cygnus.com> <3BBB56AB.4090801@cygnus.com> <3BBB5D71.1D8B51B2@cygnus.com>
X-SW-Source: 2001-10/msg00066.html

> Andrew Cagney wrote:
> 
>> 
> 
>> > May I suggest:
> 
>> >> if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)
>> >>
>> >> I'd prefer to preserve the knowledge that an object is in only one
>> >> space.
> 
>> >
>> >
>> > Sure, good suggestion.
> 
>> 
>> Remember, the number of spaces is determined by the target architecture.
>> You can probably reserve a fixed set but it may eventually overflow.
> 
> 
> And as you observed (I think), it would eventually be desireable 
> to give the target arch the ability to define the spaces.
> My hardwiring of "code" and "data" is just an initial step.
> When we make it extendable, the internal implementation may be
> entirely different, and the artificial limit on the number of
> address spaces may go away.


Ah, define code, data and I/O bits and then leave the problem of 
changing that to an enum / integer / struct ...  to the person that has 
all the address spaces.

Probably a good choice,

	Andrew