This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: harvard architectures - the d10v
- To: David Taylor <taylor at cygnus dot com>
- Subject: Re: harvard architectures - the d10v
- From: Doug Evans <dje at transmeta dot com>
- Date: Thu, 8 Feb 2001 13:30:46 -0800 (PST)
- Cc: GDB Discussion <gdb at sources dot redhat dot com>
- References: <200102082037.PAA07784@texas.cygnus.com>
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
- there could be a default address space,
or target could specify that "x/x 0x12345678 is an error
- users of targets without address spaces would see no change
- I would treat the address space names as target specific
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.