Date: Tue, 9 Oct 2012 18:16:48 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Andrey Chernov <ache@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Eitan Adler <eadler@FreeBSD.org> Subject: Re: svn commit: r241373 - head/lib/libc/stdlib Message-ID: <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org> In-Reply-To: <507451DE.9060909@freebsd.org> References: <201210091425.q99EPFS6020787@svn.freebsd.org> <507451DE.9060909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Oct 2012, at 17:33, Andrey Chernov wrote: > Do you check assembler output for _both_ cases? > In my testing clang and gcc xor's 'junk' properly in case it have > 'volatile' keyword (as in srandomdev()) and elide it without = 'volatile'. > IMHO this change should be backed out for srandomdev() and adding > 'volatile' for sranddev() instead. In it's original form, it is very dangerous - the whole expression = reduces to undefined and so the LLVM IR for the call is: call void @srand(i32 undef) The back end is then free to use any value for the call argument, = including any register value or 0. Since the value is passed in a = register, it will probably just use whatever the last value there is, = which may or may not be anything sensible. On MIPS, for example, this = is most likely to be &tv, and so is 100% deterministic. Adding the volatile means that we are doing an XOR with a value left on = the stack. If this is early on in the application, then it is most = likely to be 0. If it's later on, then there may be a value here, but = it's still not very likely to be something particularly unpredictable. =20= David=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?977E1107-46D4-476F-A04D-AEFD87D1DE53>