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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
