Re: harvard architectures - the d10v

[David Taylor <taylor at cygnus dot com>]

    Date: Thu, 08 Feb 2001 11:47:53 -0800
    From: Andrew Cagney <ac131313@cygnus.com>

    So a meta question, how should GDB behave when it comes to a harvard
    architecture?

That's a very broad question.

A vauge approximate answer is

"As the d10v behaves, but without the bugs and without the kludges."

[Of course that doesn't say "what is a bug" nor "what is a kludge".]

For the d10v there are in several files the line

  if (GDB_TARGET_IS_D10V

(Although I believe that the number of such files is diminishing over
time.)

    I've this feeling that at present we've lots of people all trying to get
    GDB to work on harvard architectures and each, in a vacuum, is
    determining how it should behave.  The unfortunately consequence is that
    when the discussion is finally dragged, kicking and screaming, out onto
    a public forum, no one agrees.  People refuse to discuss details because
    their harvard architecture is all hush, hush.  By the time the issues
    are raised, it is all too late and the real problems are simply not
    fixed.

    The ironic part to all this is that, long ago, GDB was targeted at the
    d10v (it is the extreme games version of a harvard architectures). At
    the time it was decided that the d10v hacks should to be accepted into
    gdb because that way there was at least a working implementation out
    there in a public forum.  The tool you all need to facilitate public
    discussion are available yet everyone refuses to use it!


    ``But the d10v is a hack''?  So?  The point of the d10v, wasn't to
    provide a reference implementation (anything but!) but rather to provide
    a vehicle through which a reference implementation could be developed. 
    The really important thing is to remember that this implementation has
    been 

Part of the sentence appears to be missing.

    So, who out of all of you would like to steer this to resolution?  The
    first thing I think needs to be done is for people to agree to the
    correct interaction and document it.  That way if people ever want to
    re-open the debate about what the behaviour should be they can simply
    turn to the gdb.texinfo documentation.

I'm certainly interested in this discussion, have opinions on much of
this, and am willing...  but I don't have much care who "steers" it --
so long as the discussion occurs.

	    Andrew

    --

    Anyway, onto more serious matters.  One thing I do remember as a problem
    was:

	    gdbtypes.h:builtin_type_ptr

    it isn't constructed correctly (at the time I didn't know what I was
    doing ...).  It should be cloned into:

	    builtin_type_data_ptr;  (void*)
	    builtin_type_func_ptr;  (void(*)())

Don't forget the existing msym_text_symbol_type.

    that would at least allow the POINTER_TO_ADDRESS and ADDRESS_TO_POINTER
    to be called when converting to/from generic pointers.

    Anyone?

	    Andrew

Currently, GDB and to a lesser extent the binutils/gas/ld toolsuite,
deal with Harvard Architectures by adding extra bits to allow them to
treat the system as having a unified address space.

For example, for the d10v:

. data memory starts at 0x2000000
. instruction memory starts at 0x1000000
. all addresses are byte addresses

Converting between pointers and addresses generally seems to involve

. or'ing in or masking off some high bits
. shifting the low bits by some amount