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

[Michael Snyder <msnyder@cygnus.com>]

Andrew Cagney wrote:
> 
> > + 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.

Yes, but it's a generous limitation (there are 20 more bits available).
I'll go either way -- the trade-off is that if we don't use the "flags"
field, we have to add a new field to the (struct type) data structure.

> 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 ....

Maybe, but that can be done as a follow-on extension to what I've done.
The change I've submitted works now, it doesn't require this addition
(so we don't have to decide now).

I should explain -- without this change, the way GDB currently does this
is to look at the types of expressions, and divide them into two categories:

  1) functions and things pointed to by function pointers, and
  2) everything else (which basically includes data-like objects
     (scalars, structs, arrays of data-like objects...)

The first are always treated as living in code-space, and
the second are always treated as living in data-space. 
The extension that I'm submitting merely gives the user
the ability to override that assumption (eg. to look at
data objects that have been located in code space).
If an expression is _not_ cast using the "@code" or "@data"
modifiers, then the original defaults still apply.

> 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.

Yep.  Many more changes are likely to follow, step by step.