On Sat, 1 Oct 2022 21:48:39 +0200
Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote:
> 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.
2) and/or in addition to 1) compile nuke with -fno-dse
and hope for RTL DSE to not see through. Didn't look closely if that's
sufficient for now.
HTH,
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
