Re: harvard architectures - the d10v

[David Taylor <taylor@cygnus.com>]

    From: Doug Evans <dje@transmeta.com>
    Date: Thu, 8 Feb 2001 13:30:46 -0800 (PST)

    David Taylor writes:
    >I feel that a user address should always mean the same thing.
    >And that, for example,
    >
    >    x/x 0x12345678
    >
    >    x/i 0x12345678
    >
    >should both read the same set of bytes from the target.  That the
    >interpretation of 0x12345678 -- as a specific location within a
    >specific address space -- should not depend upon whether the user
    >typed /x or /i.  That it should not be the case that one returns
    >something from the data space and the other from the instruction
    >space.
    >
    >Comments?

    Agreed.  The way I would extend this is to name the address space
    you want the address to refer to.  Without claiming this is
    the best syntax/wording/etc., maybe something like

    x/x insn:0x12345678
    x/i insn:0x12345678
    x/x data:0x12345678
    x/i data:0x12345678

I wonder if the @ syntax that Per proposed would conflict with the
array syntax.  I suspect it would, but I haven't thought much about
it.  There is precedence for using : -- segment registers on the x86
family.  But, would that conflict / cause parsing problems with other
things (.e.g, C++ uses :: and C has a ternary operator)?

x/x <expression-involving-?:-and-address-spaces>

    - there could be a default address space,
      or target could specify that "x/x 0x12345678 is an error

or the address space could be "sticky" -- that is, an address given
without an address space qualifier could use the most receently
specified address space.

    - users of targets without address spaces would see no change
    - I would treat the address space names as target specific

with probably some "standard" names that most targets would use...

One could even imagine both raw and virtual names (bad choice of words
-- would absolute and relative be better?).  For example, if you had
multiple processes, and suppose the data spaces were data1, data2,
data3...  then data might mean the data space of the 'current' process
(whatever 'current' means in this context).

    Implementation-wise, this would get translated to a CORE_ADDR
    that had two parts: address space id, and address.
    Obviously, you really don't want to fake the encoding of this
    by still have CORE_ADDR be an integral type as you have to
    worry about address calculations over/underflowing to a different
    address space.  An integral CORE_ADDR may not even be big enough to hold
    all the possiblities.  Ergo, CORE_ADDR becomes a struct.
    A simplistic count of the number of places in the source that has to
    change is about 1400 (make CORE_ADDR a struct, and process the output
    of make -k).  That's a lot.  I have heard "hallway discussions"
    where people have been thinking about making CORE_ADDR a struct,
    and it seems (though I'm by no means certain) like "the right thing to do".
    Targets without address spaces could probably keep CORE_ADDR as
    an integral type.  You'd just need to write an appropriate set
    of cover macros for definition/manipulation.

I would argue that even with a single address space you'd still want
it to be a struct (even if the address space part is identical for all
addresses), otherwise you'd have bit rot potentially setting in
whenever someone who normally only worked on a single address space
environment modified gdb.

Flip side, if it was only a struct on selected targets, then old
unconverted targets would continue to work.

The solution would probably be to initially allow it to be an integral
type on targets without multiple address spaces -- but convert some of
the most popular targets (e.g., Sparc/Solaris native, x86/Linux
native, and x86/Windows native) to the new regime.

Also, we need to have two perspectives here:

. longer term -- where do we want to go -- and I would put changing
CORE_ADDR into a struct into that category as it would require a fair
bit of work.

. shorter term -- People are porting gdb to environments with multiple
address spaces *NOW*.  In the immediate future what do we want to be
the behavior of existing commands and such.  And what should be done
immediately, if anything, to get GDB to work reasonably well in such
environments.