FW: Targeting dual Harvard architectures

FW: Targeting dual Harvard architectures

[Ken Dyck]

My employer is considering targeting gdb (and binutils) to their DSP
chip. Like many DSPs, ours is a dual Harvard architecture with three
separate memory spaces: one for instructions and two for data. There's a
fourth, if you count non-volatile EEPROM.

I understand from a thread that Andrew Cagney started in February of
2001 (http://sources.redhat.com/ml/gdb/2001-02/msg00082.html) that
although gdb has been targeted to architectures with multiple memory
spaces, like d10v and avr, by mapping each memory space into a region
within a larger address space, the results leave much to be desired.
Nick Duffek summarized the problem when he proposed a partial solution
(http://sources.redhat.com/ml/gdb/2001-02/msg00107.html).

Per Bothner proposed defining CORE_ADDR as a struct as a first
step(http://sources.redhat.com/ml/gdb/2001-02/msg00086.html). Andrew's
response to Per's proposal
(http://sources.redhat.com/ml/gdb/2001-02/msg00091.html) gives me the
impression that his idea has been discussed in gdb circles before. Does
it still have merit?

Some time before AVR support was introduced, the CODE_SPACE and
DATA_SPACE macros were added to support Harvard architectures
(http://sources.redhat.com/ml/gdb/2002-02/msg00145.html). I suppose
another macro could be added to support dual Harvard architectures. Say,
DATA_SPACE2. It seems like a kludge to me, though. Comments?

Has there been any more discussion about targeting gdb to Harvard
architectures in the gdb mailing list or elsewhere since then? I haven't
been able to find anything that seems relevant beyond what I have
referenced above. Any suggestions?

The questions that I seek to answer are these:

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.

2. What changes would be necessary?

3. How much effort would be involved in making such modifications?

Any pointers or comments would be welcome.

Ken

Re: FW: Targeting dual Harvard architectures

[Jim Blandy]

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


> 2. What changes would be necessary?

Well, at the moment, TYPE_FLAG_CODE_SPACE and TYPE_FLAG_DATA space are
just two distinct flags that could be attached to a type.  Similarly,
"@code" and "@data" are hard-coded in gdbtypes.c.  What I think we
want to do is put the vocabulary of address space flags entirely under
the control of target-specific code, via gdbarch methods.

- The type flags would be broken out into their own field of 'struct
  type' (not 'struct main_type').  It could just be an int; core GDB
  would always call gdbarch methods to operate on it, so its
  interpretation would be completely at the convenience of the
  arch-specific code.  If you wanted to be very pure, you could use a
  void * instead of an int.

- There'd be a gdbarch method for turning an address space name into
  one of these ints, for parsing, and another for turning an int into
  a name, for printing.

- At the moment, make_type_with_address_space is doing two jobs ---
  it's handling both the address space stuff, and the non-standard
  pointer type stuff (at the moment, only s/390 'mode32' pointers).
  You'd probably need to split that into two distinct functions, and
  give them better names.  Not sure here.

- You'd need to fix up the existing targets that use the type flags to
  use the new ints.  It looks like just avr-tdep.c and d10v-tdep.c.

- If it turns out that all the targets that are using these address
  spaces end up using similar code and data structures for it, you'll
  want to look at factoring things out into support functions, so
  targets with trivial needs ("I just have N address spaces named X,
  Y, Z, ...") can get what they need with trivial tdep code.

> 3. How much effort would be involved in making such modifications?

Most of the time would go into figuring out how things work now.  The
actual changes wouldn't be too bad, since it doesn't seem like there's
too much code that mucks about with this stuff; just bits here and
there.  So how good you are at finding your way through unfamiliar
code would be the dominating factor, I'd guess.

Re: FW: Targeting dual Harvard architectures

[Jim Blandy]

Jim Blandy <jimb@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!)

I've filed a bug about this.

Re: FW: Targeting dual Harvard architectures

[Eli Zaretskii]

> From: Jim Blandy <jimb@redhat.com>
> Date: 29 Oct 2003 01:07:11 -0500
> 
>   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!)

Then let's add it.

Re: FW: Targeting dual Harvard architectures

[Kevin Buettner]

On Oct 29,  1:07am, Jim Blandy wrote:

> - At the moment, make_type_with_address_space is doing two jobs ---
>   it's handling both the address space stuff, and the non-standard
>   pointer type stuff (at the moment, only s/390 'mode32' pointers).
>   You'd probably need to split that into two distinct functions, and
>   give them better names.  Not sure here.

It may also be possible to (re)implement the @code, @data mechanisms
using the address class methods.  That might be the cleanest since it
would then be possible for an architecture to do whatever it wants
with regard to adding more address spaces.  I.e. a dual Harvard
architecture could have @code, @data1, and @data2 or even more
suitable names which'd make more sense for that architecture.

Kevin

Re: FW: Targeting dual Harvard architectures

[Jim Blandy]

Kevin Buettner <kevinb@redhat.com> writes:

> On Oct 29,  1:07am, Jim Blandy wrote:
> 
> > - At the moment, make_type_with_address_space is doing two jobs ---
> >   it's handling both the address space stuff, and the non-standard
> >   pointer type stuff (at the moment, only s/390 'mode32' pointers).
> >   You'd probably need to split that into two distinct functions, and
> >   give them better names.  Not sure here.
> 
> It may also be possible to (re)implement the @code, @data mechanisms
> using the address class methods.  That might be the cleanest since it
> would then be possible for an architecture to do whatever it wants
> with regard to adding more address spaces.  I.e. a dual Harvard
> architecture could have @code, @data1, and @data2 or even more
> suitable names which'd make more sense for that architecture.

Hmm.  Address spaces are mutually exclusive of each other --- but not
of address classes.  For example, there's no reason one couldn't have
a '@mode32 @code char *'.  But what combinations are permitted and
which are nonsensical should be up to the target.

Perhaps, instead of having gdbarch methods that turn a name into an
int, we should have gdbarch methods that take a name, and the old int
(initially zero), and return the new int.  That is, let them modify
the arch-specific flag set as needed, not just specify a new flag set.

That way, Ken's architecture could set aside a bitfield for the
spaces, and allocate other bits for whatever address classes the
architecture supports.  The gdbarch method itself would recognize that
'@code @data1 @data2 char *' is a nonsensical type, and report the
error, but would know that the (hypothetical) '@mode32 @code char *'
is okay.

Re: FW: Targeting dual Harvard architectures

[Andrew Cagney]

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

Andrew

Re: FW: Targeting dual Harvard architectures

[Jim Blandy]

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.