Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 9 Oct 2012 10:27:27 -0700
From:      mdf@FreeBSD.org
To:        David Chisnall <theraven@freebsd.org>
Cc:        svn-src-head@freebsd.org, Eitan Adler <eadler@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Andrey Chernov <ache@freebsd.org>
Subject:   Re: svn commit: r241373 - head/lib/libc/stdlib
Message-ID:  <CAMBSHm8GCDvJCHYcrPBQ6awKWnmNpnS-9YgX1uAoOePjZhf9QA@mail.gmail.com>
In-Reply-To: <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org>
References:  <201210091425.q99EPFS6020787@svn.freebsd.org> <507451DE.9060909@freebsd.org> <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 9, 2012 at 10:16 AM, David Chisnall <theraven@freebsd.org> wrot=
e:
> 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 reduce=
s 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, includi=
ng any register value or 0.  Since the value is passed in a register, it wi=
ll 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 t=
he stack.  If this is early on in the application, then it is most likely t=
o be 0.  If it's later on, then there may be a value here, but it's still n=
ot very likely to be something particularly unpredictable.
>

The original behavior can be recovered by using inline assembly to
fetch the value from a register into a local C variable; this would at
least not rely on undefined behavior.  But I agree it's of dubious
value anyways.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm8GCDvJCHYcrPBQ6awKWnmNpnS-9YgX1uAoOePjZhf9QA>