From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id DDE0D3858D20 for ; Thu, 29 Feb 2024 07:32:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DDE0D3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DDE0D3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=85.10.215.148 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709191940; cv=none; b=l1e6diamHxjHZettpvjTgvc28YPNWzu9nK7htFsGpojmfvz5ifMQ2xtlHSgfI5vLvzpx2yaJpj4SgpNGAl1ERmoxDtiybc0QGrJhaK6quQpQ/YGUZI20v/gumpdWX73SKEu3lV0CxqH9z5Mt+NH//ErHQlqiL96OreGQ5djhepw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709191940; c=relaxed/simple; bh=1taz4hKHtvtuwpaW1c9NvX4Bhd94KRRXwhdU6od2H/Q=; h=Message-ID:Date:MIME-Version:To:From:Subject; b=bdoeij63I5LpSwpGM3EgWGd+tn+AaQ4968v04mbqdGxBiGim4H5hmg0prJPP2hk50PVDLgpQ1GvfSo7bSUrIs7EzO/0A3lSziipFlo75CQitks/SjuyJTG82w9tliqgQ4RJJp7U/bWAxPSzCxsL3PrkMGGfarK+H8Y2+wtLwzow= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfats-0002uu-7z for gcc-help@gcc.gnu.org; Thu, 29 Feb 2024 08:32:16 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rfats-007T1D-0C for gcc-help@gcc.gnu.org; Thu, 29 Feb 2024 08:32:16 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 952DB4800CE for ; Thu, 29 Feb 2024 08:32:15 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavis, port 10032) with ESMTP id t4j3EDNbLoUH for ; Thu, 29 Feb 2024 08:32:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3D1374801B8 for ; Thu, 29 Feb 2024 08:32:15 +0100 (CET) X-Virus-Scanned: amavis at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavis, port 10026) with ESMTP id 0oODhwKCrwrB for ; Thu, 29 Feb 2024 08:32:15 +0100 (CET) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 03FFA4800CE for ; Thu, 29 Feb 2024 08:32:14 +0100 (CET) Message-ID: Date: Thu, 29 Feb 2024 08:32:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: gcc-help From: Sebastian Huber Subject: Using -frandom-seed=0 for reproducible builds? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldi-networks.de X-Virus-Scanned: Clear (ClamAV 0.103.10/27199/Wed Feb 28 10:31:56 2024) X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, I noticed that the coverage and profiling instrumentation needs the=20 -frandom-seed flag to be reproducible. The documentation https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-frandom-s= eed says: The string should be different for every file you compile. Searching the internet suggests that using -frandom-seed=3D0 is not=20 unusual. Why should the string be different for every file you compile?=20 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,=20 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=20 across the entire link. For the coverage profiling, the -frandom-seed flag just results in=20 "local_tick" being -1. The "local_tick" is only used to initialize the=20 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=20 reproducible coverage instrumentation and don't touch the random seed stu= ff? --=20 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=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/