[2/3] Use urandom to get random seed

From: Andi Kleen <ak@linux.intel.com>

When available use /dev/urandom to get the random seem. This will lower the probability
of collisions.

On other systems it will fallback to the old methods.

Passes bootstrap + testsuite on x86_64. Ok?

gcc/:

* 2011-09-26   Andi Kleen <ak@linux.intel.com>

	* toplev.c (init_local_tick): Try reading random seed from /dev/urandom
---
 gcc/toplev.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

On Wed, Sep 28, 2011 at 2:49 PM, Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> When available use /dev/urandom to get the random seem. This will lower the probability
> of collisions.
>
> On other systems it will fallback to the old methods.
>
> Passes bootstrap + testsuite on x86_64. Ok?
>
> gcc/:
>
> * 2011-09-26   Andi Kleen <ak@linux.intel.com>
>
>        * toplev.c (init_local_tick): Try reading random seed from /dev/urandom
> ---
>  gcc/toplev.c |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 78583fc..ab6b5a4 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -262,7 +262,17 @@ init_local_tick (void)
>  {
>   if (!flag_random_seed)
>     {
> -      /* Get some more or less random data.  */
> +      /* Try urandom first. Time of day is too likely to collide.
> +        In case of any error we just use the local tick. */
> +
> +      int fd = open ("/dev/urandom", O_RDONLY);
> +      if (fd >= 0)
> +        {
> +          read (fd, &random_seed, sizeof (random_seed));

I suppose we might get interrupted before anything is read and
read can return with -1 (I suppose partial reads are quite unlikely
though)?  Thus, don't we need the usual EINTR loop?

If not, the patch is ok.

Thanks,
Richard.

> +          close (fd);
> +        }
> +
> +      /* Now get the tick anyways  */
>  #ifdef HAVE_GETTIMEOFDAY
>       {
>        struct timeval tv;
> --
> 1.7.5.4
>
>

> I suppose we might get interrupted before anything is read and
> read can return with -1 (I suppose partial reads are quite unlikely
> though)?  Thus, don't we need the usual EINTR loop?

When we get interrupted gcc will die. I don't think gcc handles any
asynchronous signals, right?

-Andi

On Wed, 28 Sep 2011 16:56:32 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> > I suppose we might get interrupted before anything is read and
> > read can return with -1 (I suppose partial reads are quite unlikely
> > though)?  Thus, don't we need the usual EINTR loop?
> 
> When we get interrupted gcc will die. I don't think gcc handles any
> asynchronous signals, right?


That depends upon the signal. If we got SIGCHLD or SIGWINCH, the call to read probably
gets EINTR, but the signal is ignored unless explicitly handled.

So I would suggest testing for EINTR.

Besides, perhaps some plugins could install their signal handlers....

Regards.

> That depends upon the signal. If we got SIGCHLD or SIGWINCH, the call to read probably
> gets EINTR, but the signal is ignored unless explicitly handled.

ignored signals do not cause EINTR no.

And I don't think either gcc.c nor toplev.c can get SIGCHLD at this point.

-Andi