Using -frandom-seed=0 for reproducible builds?

Using -frandom-seed=0 for reproducible builds?

[Sebastian Huber]

Hello,

I noticed that the coverage and profiling instrumentation needs the 
-frandom-seed flag to be reproducible. The documentation

https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-frandom-seed

says:

     The string should be different for every file you compile.

Searching the internet suggests that using -frandom-seed=0 is not 
unusual. Why should the string be different for every file you compile? 
Or, what could happen if two files use the same random seed?

It seems the random seed is only used in two places:

gcc/tree.cc:#include "toplev.h" /* get_random_seed */
gcc/tree.cc:            crc32_string (0, name), get_random_seed (false));

/* Generate a name for a special-purpose function.
    The generated name may need to be unique across the whole link.
    Changes to this function may also require corresponding changes to
    xstrdup_mask_random.
    TYPE is some string to identify the purpose of this function to the
    linker or collect2; it must start with an uppercase letter,
    one of:
    I - for constructors
    D - for destructors
    N - for C++ anonymous namespaces
    F - for DWARF unwind frame information.  */

tree
get_file_function_name (const char *type)

gcc/lto-streamer.cc:    sprintf (post, "." HOST_WIDE_INT_PRINT_HEX_PURE, 
get_random_seed (false));

char *
lto_get_section_name (int section_type, const char *name,
		      int node_order, struct lto_file_decl_data *f)
{
[...]
   /* Make the section name unique so that ld -r combining sections
      doesn't confuse the reader with merged sections.

      For options don't add a ID, the option reader cannot deal with them
      and merging should be ok here. */

I am not sure which bad things happen if some items are not unique 
across the entire link.

For the coverage profiling, the -frandom-seed flag just results in 
"local_tick" being -1. The "local_tick" is only used to initialize the 
random seed and in coverage.cc for a file stamp for notes file.

Would it make sense to add a new option to just control "local_tick" for 
reproducible coverage instrumentation and don't touch the random seed stuff?

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: Using -frandom-seed=0 for reproducible builds?

[Alexander Monakov]

On Thu, 29 Feb 2024, Sebastian Huber wrote:

> Hello,
> 
> I noticed that the coverage and profiling instrumentation needs the
> -frandom-seed flag to be reproducible. The documentation
> 
> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-frandom-seed
> 
> says:
> 
>     The string should be different for every file you compile.
> 
> Searching the internet suggests that using -frandom-seed=0 is not unusual.

Heh, -frandom-seed=0 is the same as not passing -frandom-seed at all:
get_random_seed reseeds random_seed if it is zero.

> Why should the string be different for every file you compile?

In very rare circumstances GCC relies on random identifiers not colliding
at link stage. One example I'm aware of is global constructors on AIX
(which used the COFF object file format, not ELF). If you deliberately
construct a testcase where two constructor function get the same section
name, you get a linker warning:

ld: 0711-224 WARNING: Duplicate symbol: global constructors keyed to 65535_0_t.c_00000000_0xb3fc9bb6
ld: 0711-224 WARNING: Duplicate symbol: .global constructors keyed to 65535_0_t.c_00000000_0xb3fc9bb6
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

and one of the constructors is not executed (a correctness issue). On ELF
targets this issue does not arise.

> Or, what could happen if two files use the same random seed?

Per the above, the program may be miscompiled.

> For the coverage profiling, the -frandom-seed flag just results in
> "local_tick" being -1. The "local_tick" is only used to initialize the random
> seed and in coverage.cc for a file stamp for notes file.
> 
> Would it make sense to add a new option to just control "local_tick" for
> reproducible coverage instrumentation and don't touch the random seed stuff?

I am not sure why you'd want to do that, but FWIW the usual trick
is to pass the source file name as the seed:

    gcc -c src/foo.c -frandom-seed=src/foo.c

this way each file with high probability gets a reproducible unique seed.

Alexander