[PATCH] memset 0 in obscure is optimized away by compiler

[Bernhard Reutner-Fischer]

On Wed, 16 Apr 2014 20:25:39 -0400

> That's exactly the situation here. The lifetime of the object being
> cleared by memset ends sufficiently close to the memset that the
> compiler is able to achieve the same observable effects that would be
> seen in the abstract machine without actually performing any memory
> fill.

There are several possibilities out there in the wild that currently
work around the (unimplemented, everywhere) microsoft _s "extension".

1)
memset(ptr, 0, length-of-ptr-to-data);

#define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory")
barrier_data(ptr);

2)
through volatile function pointer for C99 (that's what we have ATM)
typedef void *(*memset_fn_t)(void *,int,size_t);
static volatile memset_fn_t memset_fun = &memset;
void my_c99_memset(void *ptr, size_t len) {
  memset_fun(ptr, 0, len);
}
Several, e.g. https://klevchen.ece.illinois.edu/pubs/yjoll-usesec17.pdf

3) ...

Hence
1) is what's currently used in the kernel (include/linux/compiler.h,
barrier_data). I'd do that, too, for now, IMO.

and there's -fno-inline-memset for compiling nuke, but i haven't looked
in detail if that confuses DSE enough to give up on the memset in our
nuke.

HTH,