Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney <ac131313 at cygnus dot com>]

> + extern char *
> + address_space_int_to_name (int space_flag)
> + {
> +   if (space_flag & TYPE_FLAG_CODE_SPACE)
> +     return "code";
> +   else if (space_flag & TYPE_FLAG_DATA_SPACE)
> +     return "data";
> +   else
> +     return NULL;
> + }
> + 

Some thoughts on the internals.

Should these spaces be flags or an enumeration?  I don't think being 
able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks 
also puts a limitation on the number of spaces.

Should a flag  always be set (if not specified explicitly).  For 
instance, a ``(*)()'' which implies the code space explicitly setting it 
as such?  That will make some of the pointer to/from address code easier 
- just check the space - no need to test for func or method or ....

I suspect that this is going to slowly affect other parts. At present 
there is a singe TARGET_PTR_BIT.  Given different address spaces can 
have different sizes, that macro will be replaced by a more generic 
(target_space_ptr_bit (space).

As you note, for the moment text/data are hardwired / pre-defined 
Eventually the target architecture will want an oportunity to define 
other spaces.  That can follow.

Andrew

PS: I keep reading type_as_type as type as type :-)