From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id 4F184385842A for ; Wed, 29 Nov 2023 13:40:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F184385842A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4F184385842A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701265213; cv=none; b=kytwbofxo/6tAU2GMSHKGeyRgQ/IuXTWCzCCLXiQN/0JhyWXaBI5ToucHDakvqnVsXuZyQnH3YbCf/xzT/XWFyX9U11wSVzCF4HzBBIyfg9a5jNgdT2rnnlX+gIYYSRpsLcI9zwC+xhMmgmPsCXQCigYwAYW44HPjbfeiidCk4A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701265213; c=relaxed/simple; bh=VBGeuCwPSpq3ocNgBkSNq6FbJCdQWDoeSAN1pva4ksI=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=CemJqXeukm4NMBIhCXzN8Ffw1Bkvr1IbHGNKgdLyo1Qnbw7D05qithpeA4b6jLVxo7vJnp6yR98iQ7W+4Wq/8C5M4PZEjWBAhsH3dVdKUlVi8z6a+sZeiP++/UoxnXoP+Kq9HIcIEnXKjgpNoVClPyKlUbr809wmaBWTZB0aKF8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (unknown [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 7ABC01FCE9; Wed, 29 Nov 2023 13:40:11 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A93BB2C15C; Wed, 29 Nov 2023 13:40:10 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 80C90656A; Wed, 29 Nov 2023 13:40:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 7E8E36565; Wed, 29 Nov 2023 13:40:10 +0000 (UTC) Date: Wed, 29 Nov 2023 13:40:08 +0000 (UTC) From: Michael Matz To: Nick Clifton cc: Jakub Jelinek , binutils@sourceware.org Subject: Re: [PATCH] libiberty, ld: Use x86 HW optimized sha1 In-Reply-To: <653f2d44-4a6c-4c17-9a31-e2912cf39c75@redhat.com> Message-ID: References: <653f2d44-4a6c-4c17-9a31-e2912cf39c75@redhat.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: Authentication-Results: smtp-out2.suse.de; none X-Rspamd-Server: rspamd2 X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Score: -4.00 X-Rspamd-Queue-Id: 7ABC01FCE9 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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, On Wed, 29 Nov 2023, Nick Clifton wrote: > That makes sense. But what if rather than the input to the linker changing > the linker itself changes ? For example suppose that ld.bfd supported a > --build-id=fast option which used the sha1 algorithm. Then in the next > release we decide to change the algorithm to something else, eg blake3. > Then using the 2.41 linker would produce a different build-id for the > same input as the 2.42 linker. Yes. I personally wouldn't be surprised by this, I consider the linker itself to be an input as well :) Some things in the linker output depend on algorithmic decisions, string merging and its hash-table implementation for instance. Details in the used linker scripts might change as well (section/segment alignment, order). So, when a new linker produces the same output it's mere luck (even if fairly likely usually). > I actually like the idea of supporting descriptive names for the > --build-id option, but I think that we might need to include some > caveats in the documentation... Yes, I think that would be a matter for documentation. OTOH: descriptive names might be a bikeshed hellhole :) What if we were to add a say "secure" and a "fast" name now. But how to somehow document how much less "secure" (whatever that means in this context) the fast variant is? And how much faster is it? And what if someone comes and implements a fast version of secure that happens to be even faster? Call it "secure-and-even-faster-than-old-fast"? ;-) Hmm hmm. Ciao, Michael.