From: Andreas Franck <afranck@gmx.de>
To: David Howells <dhowells@cambridge.redhat.com>
Cc: dhowells@cambridge.redhat.com, torvalds@transmeta.com,
andrewm@uow.edu.au, bcrl@redhat.com, alan@lxorguk.ukuu.org.uk,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2nd try: i386 rw_semaphores fix
Date: Wed, 11 Apr 2001 16:32:25 +0200 (MEST) [thread overview]
Message-ID: <1098.986999545@www17.gmx.net> (raw)
In-Reply-To: <16795.986998639@warthog.cambridge.redhat.com>
Hello David and people,
> I've just consulted with one of the gcc people we have here, and he says
> that
> the '"memory"' constraint should do the trick.
>
> Do I take it that that is actually insufficient?
I don't remember exactly, it's been a while, but I think it was not
sufficient when I came up with this change. I can look at it in a few
hours.
The GCC manual is not really precise here:
> If your assembler instruction modifies memory in an unpredictable fashion,
> add `memory' to the list of clobbered registers. This will cause GNU CC to
> not keep memory values cached in registers across the assembler
> instruction. You will also want to add the volatile keyword if the memory
> affected is not listed in the inputs or outputs of the
> asm, as the `memory' clobber does not count as a side-effect of the asm.
So 'memory' alone won't probably do the trick, as caching is not the
problem here, but the unknown storage size of the semaphore.
Perhaps the __voaltile__ will help, but I don't know.
What are the reasons against mentioning sem->count directly as a "=m"
reference? This makes the whole thing less fragile and no more dependent
on the memory layout of the structure.
Greetings,
Andreas
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
next prev parent reply other threads:[~2001-04-11 14:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3AD45EC5.81EB82AD@akustik.rwth-aachen.de>
2001-04-11 14:17 ` [PATCH] 2nd try: i386 rw_semaphores fix David Howells
2001-04-11 14:32 ` Andreas Franck [this message]
2001-04-11 14:43 ` David Howells
2001-04-11 15:00 ` Andreas Franck
2001-04-11 15:14 ` Bernd Schmidt
2001-04-11 18:27 ` Linus Torvalds
2001-04-12 8:38 ` Jamie Lokier
2001-04-10 19:42 [PATCH] " Linus Torvalds
2001-04-11 12:57 ` [PATCH] 2nd try: " David Howells
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=1098.986999545@www17.gmx.net \
--to=afranck@gmx.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrewm@uow.edu.au \
--cc=bcrl@redhat.com \
--cc=dhowells@cambridge.redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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 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.