This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Harvard proposal


Nick Duffek <nsd@redhat.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.)

>   <component>   
>      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
different things.

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

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.
bit/byte/word).

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]