ack, thanks - in that case, it's a nice example, but not really relevant to what we're asking about
Peter On 30 June 2015 at 00:21, Andreas Hollmann <hollm...@in.tum.de> wrote: > Sorry for my first misleading email. The code needs disabled > optimizations to ensure that the execution time is long enough > to measure jitter. It has nothing to do with the correctness of the > C code. It might be still an issue, to depend on an optimization level. > > "To ensure that optimizations are the problem of the insufficient > execution jitter as the execution time is made too fast on fast, > but less complex CPUs, the same test without optimizations is > invoked again. To compile code without optimizations, > either use no special flags or -O0." > > 2015-06-29 22:19 GMT+02:00 Andreas Hollmann <hollm...@in.tum.de>: >> There is some recent code added to Linux 4.2, that relies on disabled >> optimization. >> This might be an interesting case of unclear interpretation/misuse of >> the C language. >> >> #ifdef __OPTIMIZE__ >> #error "The CPU Jitter random number generator must not be compiled >> with optimizations. >> See documentation. Use the compiler switch -O0 for compiling >> jitterentropy.c." >> #endif >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/crypto/jitterentropy.c >> >> Documentation: http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html >> >> 2015-06-27 1:48 GMT+02:00 Peter Sewell <peter.sew...@cl.cam.ac.uk>: >>> On 26 June 2015 at 20:27, Joseph Myers <jos...@codesourcery.com> wrote: >>>> On Fri, 26 Jun 2015, Peter Sewell wrote: >>>> >>>>> > It's s simple matter of points-to analysis. &foo + anything may be >>>>> > assumed (in practice) to point to something within foo (or just past the >>>>> > end) and not to alias anything accessed through a pointer based on &bar. >>>>> > If the compiler can see something like &foo + (&bar - &foo) there is no >>>>> > guarantee of whether it will assume it to point within foo or bar and >>>>> > that >>>>> > may not be consistent for different uses (so it may end up concluding >>>>> > the >>>>> > pointer compares unequal to itself). >>>>> >>>>> Ok, that's fine in some (perhaps most) situations, but it's not >>>>> compatible with what seems to be a significant body of systems code >>>>> out there - people mentioned important usages in FreeBSD, Linux, QEMU, >>>>> and other places. How can these be reconciled? We imagine: >>>> >>>> Does that code actually access the same object via both routes in code >>>> that might get moved past each other (or values get reused because the >>>> compiler didn't think they could have changed) as a consequence of the >>>> points-to analysis? If the aliasing isn't visible, it's less likely to >>>> cause problems. >>> >>> It's a good question - quite possibly not, though it's hard to >>> investigate; really we have no idea. But I'm not sure how we could >>> state a condition like that precisely in some reasonable way, and if >>> the conditions under which this is safe become too complex, that in >>> itself becomes a failing in the language definition - at the end of >>> the day, it has to be comprehensible. >>> >>> More generally, the programming-language design tradeoff between >>> simplicity on the one hand and performance and expressivity on the >>> other is always a difficult thing to manage. The wide range of >>> opinions out there about what C behaviour can be relied on suggests >>> that C may have veered too far to the latter in some respects. >>> >>>>> a) Compilation of that systems code could turn off this analysis (and >>>>> whatever optimisation depends on it) entirely. What's the cheapest >>>>> way to do that? >>>> >>>> I think -fno-tree-pta should disable it (I don't know what the cost of >>>> that is). >>> >>> thanks, >>> Peter >>> >>> >>>> -- >>>> Joseph S. Myers >>>> jos...@codesourcery.com
