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

[Jim Blandy <jimb@zwingli.cygnus.com>]

Michael Snyder <msnyder@cygnus.com> writes:
> > 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.

(This is a suggested enhancement to Michael's patch; I think it's a
step forward as is.)

Instead of using bits, what if we added a new `const char *' field to
`struct type'?  Its value would be a string indicating the name of the
space qualifier applied to the type, or zero indicating the default.
The set of permitted space names would be determined by the
architecture, following some basic conventions (like `data' and
`code').  There would be a gdbarch method like this:

- int gdbarch_valid_addr_space_name_p (struct gdbarch *A, const char *NAME);
  Return non-zero if NAME is a valid name of an address space
  for architecture A.

The parser would recognize `@ IDENTIFIER' as a space qualifier, call
gdbarch_valid_addr_space_name_p to check it, and drop the value into
the type it creates if so.

The type printer would simply printf ("@%s", type->space); when printing.

There would be a core function:

- const char *type_default_addr_space (struct type *T);
  Return "code" if T is a pointer to function or method; return "data"
  otherwise.

The POINTER_TO_ADDRESS and ADDRESS_TO_POINTER methods, which are the
ones who actually *use* this info, receive the type object already,
and can check the space as appropriate.