From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: How to add core addresses (or LM_ADDR problems revisited)
Date: Wed, 03 Oct 2001 01:03:00 -0000 [thread overview]
Message-ID: <1011003080243.ZM22427@ocotillo.lan> (raw)
In-Reply-To: <3BBA7ED7.50205@cygnus.com>
On Oct 2, 10:58pm, Andrew Cagney wrote:
> Looking at the proposal:
>
> > CORE_ADDR
> > core_addr_add (CORE_ADDR addr1, CORE_ADDR addr2)
>
> Thinking of C, I suspect two operators are required:
>
> CORE_ADDR core_addr_add (CORE_ADDR addr, LONGEST offset);
> LONGEST core_addr_sub (CORE_ADDR a1, CORE_ADDR a2);
First, I'll note that I've already implemented core_addr_sub(), but it
wasn't different enough from core_addr_add() to merit being included
in my earlier post. The version that I implemented returns a
CORE_ADDR though.
Second, regarding the types, I (initially) also thought that an offset
should be represented as some other type (than a CORE_ADDR), but in
the process of converting existing GDB code to use core_addr_add() and
core_addr_sub(), I've found that the type of the offset is almost
always a CORE_ADDR. (Maybe even always.) I suppose it's possible that
we simply have this detail wrong, but I'm reluctant to change it at
the moment. (It's rather pervasive...)
> Don't forget that the MIPS expects sign extension so that will need to
> be handled from day one. I suspect core_addr_add() and core_addr_sub()
> are the things to multi-arch.
Okay, I'll take a look at this.
> Any way, yes, I think this is long overdue!
Cool. I'll continue work on it and send out a patch once I've
figured out what to do about MIPS. My initial patch will handle
all of the expressions involving ANOFFSET() or expressions which
get their value from an ANOFFSET assignment. Obviously, there are
a lot of other expressions involving CORE_ADDR which will eventually
need to be converted, but the ANOFFSET related ones are a good
starting point since it fixes the LM_ADDR problem.
> PS: The comment should suggest gdbarch_data() not gdbarch_swap() :-)
I considered this, but I was trying to avoid the function call needed
to fetch the data! However, I'll revise the comment so that it
mentions gdbarch_data() as well. I'll also discuss the pros and cons
of each in this setting.
Thanks for your feedback.
Kevin
next prev parent reply other threads:[~2001-10-03 1:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-02 18:31 Kevin Buettner
2001-10-02 19:59 ` Andrew Cagney
2001-10-03 1:03 ` Kevin Buettner [this message]
2001-10-03 8:50 ` Andrew Cagney
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=1011003080243.ZM22427@ocotillo.lan \
--to=kevinb@cygnus.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.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