Date: Wed, 11 Apr 2001 16:32:25 +0200 (MEST)
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
MIME-Version: 1.0
In-Reply-To: <16795.986998639@warthog.cambridge.redhat.com>
Subject: Re: [PATCH] 2nd try: i386 rw_semaphores fix
Message-ID: <1098.986999545@www17.gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/