Re: FW: Targeting dual Harvard architectures

[Jim Blandy <jimb at redhat dot com>]

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