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

Andrew Cagney
2001-09-28T13:50:00Z

> + 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 :-)