Re: FW: Targeting dual Harvard architectures

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@redhat.com> writes:
> > "Ken Dyck" <Ken.Dyck@dspfactory.com> writes:
> >
> >> 1. Is it possible to modify gdb to support architectures with multiple
> >> memory spaces in a "user friendly" way (where "user friendly" is
> >> something like what David Taylor described in
> >> http://sources.redhat.com/ml/gdb/2001-02/msg00090.html)? So far my
> >> impression is yes.
> > Yes --- with the understanding that it's restricted to just distinct
> > code and data spaces at the moment --- you can say:
> >   x/i (@code char *) 0x1234
> >   x/i (@data char *) 0x1234
> > and it'll do the right thing, if you define the ADDRESS_TO_POINTER
> > and
> > POINTER_TO_ADDRESS methods appropriately.
> > (Hey, this isn't in the GDB manual anywhere!)
> > But you've actually got a case where this needs to be extended to
> > support an arbitrary set of architecture-defined spaces, which the
> > current code does not support.  If I recall correctly, this was
> > discussed when the current @code and @data support went in, but it was
> > left as a future extension, since we didn't know of any architectures
> > that actually wanted it.  Now we do.
> 
> Yep.  The original patch was integrated with the understanding that
> the hard-wired "code" and "data" namespaces would eventually be
> replaced with a generic address space naming mechanism (ex, 86 and
> @code @data @stack and @io).
> 
> For a broad idea of how it can be implemented, look at reggroups (and
> maint print register-groups).  It lets an architecture define an
> arbitrary number of register groupings.

Yeah, reggroups might be a nice model to imitate here.  They were very
straightforward to add to an unreleased port I was working on
recently --- not fussy at all.

The only thing I worry about is that, while reggroups exist mostly for
GDB's internal benefit (save/restore) and for user interface
(general/vector), the address spaces are a real part of the
architecture, so they have to model whatever freakyness the hardware
designers can come up with.

I was originally thinking, "Address spaces are mutually exclusive;
there's no way that attaching two address space qualifiers to a type
could be meaningful.  That's gotta be an error."  But when I think
about all the weird architectures out there, I'm really inclined to
just provide the expression syntax and space in 'struct type' to let
the architecture do *whatever it wants* with the address<->pointer
relationship, and have the architecture-independent code keep its
hands clean.  If there is some order to all this, let it come from the
architecture, rather than presuming it in the arch-independent code.