From: "Maciej W. Rozycki" <macro@mips.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sourceware.org, David Ung <davidu@mips.com>,
"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: mips-tdep.c: Sign-extend pointers for n32
Date: Wed, 19 Dec 2007 16:16:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.61.0712191530370.18015@perivale.mips.com> (raw)
In-Reply-To: <20071219152826.GA30488@caradoc.them.org>
On Wed, 19 Dec 2007, Daniel Jacobowitz wrote:
> What happens to an 8-bit unsigned char? How about an 8-bit signed
> char?
Hmm, you have made me wonder... Obviously 32-bit integer quantities are
special -- they are always sign-extended so that 32-bit ALU operations may
be used on them. There is this statement in the ABI document:
"All integer parameters are promoted (that is, sign- or zero-extended to
64-bit integers and passed in a single register). Typically, no code is
required for the promotion."
This note about no code requirement may be misleading -- this may be true
for the run time, because the use of "lb/lbu/lh/lhu" as appropriate would
have had the effect of doing the correct extension when the value was
fetched into a register originally, but here we are in a different
position as it is GDB that is the caller. Let me dig through the
document... Nothing relevant apparently found.
But in practice it should not matter -- however you represent 8-bit and
16-bit quantities you cannot overflow into the 64-bit data space as with a
flip of the bit #31 the upper 32 bits follow and when a result is written
back to memory or is otherwise finally processed (like output in a textual
form) it has to be masked to its data width again (obviously "sb/sh" do
this implicitly). So I believe the change is correct as it is and the
question is academic. Let me know if you think otherwise.
> What ABI is that? I thought none of the ELF targets used n32 or n64,
> but maybe SDE is an exception.
N32, as documented in "MIPSpro N32 ABI Handbook" from SGI. I can chase a
link if you cannot locate the PDF. The SDE target uses it as the default
64-bit ABI implied by the "-mips64" switch.
Maciej
next prev parent reply other threads:[~2007-12-19 16:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 14:43 Maciej W. Rozycki
2007-12-16 18:49 ` Daniel Jacobowitz
2007-12-19 15:27 ` Maciej W. Rozycki
2007-12-19 15:28 ` Daniel Jacobowitz
2007-12-19 16:16 ` Maciej W. Rozycki [this message]
2007-12-19 17:08 ` Daniel Jacobowitz
2007-12-20 16:41 ` Maciej W. Rozycki
2007-12-20 17:07 ` Daniel Jacobowitz
2007-12-20 17:18 ` Maciej W. Rozycki
2007-12-20 19:37 ` Daniel Jacobowitz
2007-12-21 4:36 ` Joel Brobecker
2007-12-21 11:34 ` Maciej W. Rozycki
2007-12-21 11:51 ` Joel Brobecker
2007-12-21 12:02 ` Maciej W. Rozycki
2007-12-22 5:30 ` Joel Brobecker
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=Pine.LNX.4.61.0712191530370.18015@perivale.mips.com \
--to=macro@mips.com \
--cc=davidu@mips.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=macro@linux-mips.org \
/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