This is the mail archive of the 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 <> 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?

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

>     Return real data address ADDR converted to an internal gdb address.
>     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.

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

	--Per Bothner

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