From: Per Bothner <per@bothner.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: Harvard proposal
Date: Sat, 10 Feb 2001 13:27:00 -0000 [thread overview]
Message-ID: <m2itmiusrc.fsf@kelso.bothner.com> (raw)
In-Reply-To: <200102102025.f1AKPtS11061@rtl.cygnus.com>
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/
next prev parent reply other threads:[~2001-02-10 13:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-10 12:19 Nick Duffek
2001-02-10 13:27 ` Per Bothner [this message]
2001-02-10 17:11 ` Nick Duffek
2001-02-23 17:25 ` Andrew Cagney
2001-02-23 20:27 ` Per Bothner
2001-02-26 8:34 ` Andrew Cagney
2001-02-26 8:49 ` Per Bothner
2001-02-26 10:13 ` Andrew Cagney
2001-02-13 13:22 ` Andrew Cagney
2001-02-13 13:35 ` Nick Duffek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2itmiusrc.fsf@kelso.bothner.com \
--to=per@bothner.com \
--cc=gdb@sources.redhat.com \
--cc=nsd@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox