From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@oss.sgi.com
Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs
Date: Thu, 24 May 2001 16:44:59 -0700 [thread overview]
Message-ID: <20010524164459.A19466@nevyn.them.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1010524134521.6990F-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, May 24, 2001 at 03:42:56PM +0200
On Thu, May 24, 2001 at 03:42:56PM +0200, Maciej W. Rozycki wrote:
> On Wed, 23 May 2001, Daniel Jacobowitz wrote:
>
> > The ll/sc constructs in the kernel use ".set noat" to inhibit use of $at,
> > and proceed to use it themselves. This is fine, except for one problem: the
> > constraints on memory operands are "o" and "=o", which means offsettable
> > memory references. If I'm not mistaken, the assembler will (always?)
> > turn these into uses of $at if the offset is not 0 - at least, it certainly
> > seems to do that here (gcc 2.95.3, binutils 2.10.91.0.2). Just being honest
> > with the compiler and asking for a real memory reference does the trick.
>
> Both "m" and "o" seem to be incorrect here as both are the same for MIPS;
> "R" seems to be appropriate, OTOH. Still gcc 2.95.3 doesn't handle "R"
> fine for all cases, but it works most of the time and emits a warning
> otherwise. I can't comment on 3.0.
They aren't the same for MIPS, though. I exhibit as evidence the fact
that my patch fixed the problem I was seeing. I didn't know about 'R';
I suppose that it is more correct. 'm' at least is closer than 'o',
though.
If 'R' will behave correctly, could that be applied to CVS, then?
> Note that if noat is in effect and at is to be used, gas should bail out
> with an error. There is a bug, if it doesn't.
It issues a warning, currently (2.10.91.0.2 - I think 2.11 behaves the
same).
--
Daniel Jacobowitz Debian GNU/Linux Developer
Monta Vista Software Debian Security Team
next prev parent reply other threads:[~2001-05-24 23:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-23 21:52 [PATCH] incorrect asm constraints for ll/sc constructs Daniel Jacobowitz
2001-05-24 13:42 ` Maciej W. Rozycki
2001-05-24 23:44 ` Daniel Jacobowitz [this message]
2001-05-25 13:13 ` Maciej W. Rozycki
2001-05-25 21:15 ` Kevin D. Kissell
2001-05-25 21:15 ` Kevin D. Kissell
2001-05-25 21:49 ` Daniel Jacobowitz
2001-05-26 22:14 ` Kevin D. Kissell
2001-05-26 22:14 ` Kevin D. Kissell
2001-05-26 22:23 ` Ralf Baechle
2001-05-28 11:20 ` Maciej W. Rozycki
2001-05-28 13:48 ` Kevin D. Kissell
2001-05-28 13:48 ` Kevin D. Kissell
2001-05-28 13:59 ` Maciej W. Rozycki
2001-05-25 20:27 ` Ralf Baechle
2001-05-25 20:49 ` Daniel Jacobowitz
2001-05-28 11:09 ` Maciej W. Rozycki
2001-05-30 0:17 ` Daniel Jacobowitz
2001-05-30 7:02 ` Kevin D. Kissell
2001-05-30 7:02 ` Kevin D. Kissell
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=20010524164459.A19466@nevyn.them.org \
--to=dan@debian.org \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.