i386 memory fence incompatible with valgrind

Matthias Urlichs matthias at urlichs.de
Wed Jan 11 18:01:10 CET 2017

On 11.01.2017 09:10, Marc Lehmann wrote:
> The fence doesn't use an uninitialised value.

? It accesses -1(%sp), which is not initialized / undefined / whatever;
it then processes that value (by ORing it into a register). The fact
that the result is then thrown away is immaterial; valgrind's rule is
that anything that's not a copy triggers the report.

So even if I can convince the valgrind people to ignore the
below-the-stack access itself (which is an error in every other case you
might think of), the checker would immediately raise another error
because that value is used. I seriously doubt that they'll implement
another special case for handling this – when an inconsequential change
from -1 to zero in your code would work just as well.

> The code is taken from linux, so if you see 0, you are probably looking
> at a diferent version.

You may remember that you (or somebody) took that code from Linux, but
that memory is faulty. I checked.
The current kernel uses "lock; addl %0,0(%%esp)".
That code has been introduced in version 2.1.95, and before that it was
a simple compiler-only memory barrier.

-- Matthias Urlichs

More information about the libev mailing list