From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: Recent assembler sign extension patch
Date: Mon, 14 Sep 2009 13:26:47 +0000 [thread overview]
Message-ID: <20090914132646.GC21091@linux-sh.org> (raw)
In-Reply-To: <20090827132813.GB4668@console-pimps.org>
On Mon, Sep 14, 2009 at 02:12:34PM +0900, Nobuhiro Iwamatsu wrote:
> 2009/8/28 Matt Fleming <matt@console-pimps.org>:
> > Index: gas/config/tc-sh.c
> > =================================> > RCS file: /cvs/src/src/gas/config/tc-sh.c,v
> > retrieving revision 1.132
> > diff -u -r1.132 tc-sh.c
> > --- gas/config/tc-sh.c ?24 Jul 2009 11:45:00 -0000 ? ? ?1.132
> > +++ gas/config/tc-sh.c ?27 Aug 2009 20:09:14 -0000
> > @@ -156,6 +156,11 @@
> > ?#define ENCODE_RELAX(what,length) (((what) << 4) + (length))
> > ?#define GET_WHAT(x) ((x>>4))
> >
> > +/* Truncate and sign-extend at 32 bits, so that building on a 64-bit host
> > + ? gives identical results to a 32-bit host. ?*/
> > +#define TRUNC(X) ? ? ? ((long) (X) & 0xffffffff)
> > +#define SEXT(X) ? ? ? ? ? ? ? ?((TRUNC (X) ^ 0x80000000) - 0x80000000)
> > +
> > ?/* These are the three types of relaxable instruction. ?*/
> > ?/* These are the types of relaxable instructions; except for END which is
> > ? ?a marker. ?*/
> > @@ -4183,7 +4188,7 @@
> > ? ? ? ?val = ((val >> shift)
> > ? ? ? ? ? ? ? | ((long) -1 & ~ ((long) -1 >> shift)));
> > ? ? }
> > - ?if (max != 0 && (val < min || val > max))
> > + ?if (max != 0 && (SEXT(val) < min || SEXT(val) > max))
> > ? ? as_bad_where (fixP->fx_file, fixP->fx_line, _("offset out of range"));
> > ? else if (max != 0)
> > ? ? /* Stop the generic code from trying to overlow check the value as well.
>
> I think that I should cope in a kernel, because this problem is thing
> by the limit of mov.
> # mov of this case supports only 8bit.
>
The whole reason that the toolchain patch is necessary is because 64-bit
hosts weren't doing sign extension on a truncated 32-bit value, which is
a legitimate bug.
As far as the mov size, a manually sign extended value is perfectly
acceptable, and any toolchain should be intelligent enough to get the
size calculation right. It's obviously not entirely elegant, but it's
much less confusing than running in to situations where the same
immediate is used and it may or may not be sign extended, depending on
which instruction it gets used with. That ambiguity is what this approach
solves, and I think it is definitely worthwhile trying to keep it as
simple as possible to prevent sign extension bugs from popping up.
If you've ever had to chase a sign extension bug, you will appreciate the
value of this (especially given the sometimes rather inconsistent
instruction set).
next prev parent reply other threads:[~2009-09-14 13:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 13:28 Recent assembler sign extension patch Matt Fleming
2009-08-27 13:35 ` Paul Mundt
2009-08-27 14:39 ` Stuart MENEFY
2009-08-27 20:13 ` Matt Fleming
2009-09-14 5:12 ` Nobuhiro Iwamatsu
2009-09-14 13:26 ` Paul Mundt [this message]
2010-01-27 7:29 ` Rob Landley
2010-01-27 7:55 ` Paul Mundt
2010-01-29 7:53 ` Rob Landley
2010-01-29 15:23 ` Paul Mundt
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=20090914132646.GC21091@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-sh@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).