This is the mail archive of the
mailing list for the GDB project.
Re: Harvard proposal
- To: Nick Duffek <nsd at redhat dot com>
- Subject: Re: Harvard proposal
- From: Per Bothner <per at bothner dot com>
- Date: 10 Feb 2001 13:34:31 -0800
- Cc: gdb at sources dot redhat dot com
- References: <200102102025.f1AKPtS11061@rtl.cygnus.com>
Nick Duffek <email@example.com> writes:
(Note: While I do question some of your concepts, there are a lot of
Gdb issues I'm unaware of. So the questions are meant as real
questions, not rhetorical, and a request for a better explanation.)
> REAL user-visible and hardware addresses
The word "REAL" is poorly chosen. Is a "REAL" address an integer?
What about DEC-10-style "byte pointers"? These were a triple (word
address, bit offset, bit count). You might want to represent this
in gdb as a (36-bit) integer, but you probably don't want to print
them as a hex integer. Thus "user-visible" and "hardware" are two
> OBJ symbol and entry-point addresses in object files
What is this? File position from start of file? (Why should anyone
except the object file reader care?) Offset from start of section?
Isn't that just a relative address - i.e. an integer?
> REMOTE addresses specified to remote target for memory I/O
How is this different from REAL?
> ADDR_IN_GDB_INSN (CORE_ADDR addr)
> Return internal gdb address ADDR converted to an internal gdb
> instruction address if it isn't one already.
I have no idea what this is supposed to be.
> ADDR_IN_REAL_DATA (CORE_ADDR addr)
> Return real data address ADDR converted to an internal gdb address.
> ADDR_IN_REAL_INSN (CORE_ADDR addr)
> Return real instruction address ADDR converted to an internal gdb
I think you're starting at the wrong end. The lesson of thirty years
of programming methodology is: Start with the data types (or objects).
So we need to agree what CORE_ADDR is. If most people think that
ultimately CORE_ADDR should be a struct, it is because CORE_ADDR is
the data type that gdb uses internally to represent an address. So
either I've misunderstood you, or you got it backwards:
ADDR_IN_REAL_DATA and ADDR_IN_REAL_INSN take an integer argument and
*return* a CORE_ADDR; they do not *take* CORE_ADDRs.
> ADDROFF_OUT_REAL (CORE_ADDR addr, CORE_ADDR offset)
> Return internal gdb address OFFSET from ADDR converted to a real
> address offset.
An "offset" needs to be a different datatype from a CORE_ADDR.
An offset is just a plain integer (and perhaps a "unit" e.g.