From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D8BCC30653 for ; Sun, 7 Jul 2024 07:12:39 +0000 (UTC) Subject: Re: Rust reproducibility issue summary To: openembedded-core@lists.openembedded.org From: "Sundeep KOKKONDA" X-Originating-Location: Hyderabad, Telangana, IN (49.205.253.192) X-Originating-Platform: Windows Chrome 126 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Sun, 07 Jul 2024 00:12:35 -0700 References: In-Reply-To: Message-ID: <20061.1720336355685054373@lists.openembedded.org> Content-Type: multipart/alternative; boundary="panb6GDXqgZdFmytDTSN" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Sun, 07 Jul 2024 07:12:39 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/201617 --panb6GDXqgZdFmytDTSN Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 5, 2024 at 08:55 PM, Alexander Kanavin wrote: >=20 > After reading the issue and poking at the rustdoc binaries on my local > disk, I think the key is in finding where those llvm. suffixes are > generated and *how*. Something (presumably rust-llvm) puts them there, so > narrowing down to the point where that non-reproducible value is decided > would help a lot in finding out why it sometimes changes. It does require > navigating and reading a mountain of unfamiliar llvm code, this is what > makes the issue difficult. The.llvm. are generated by ThinLTO optimizations, and this is enabled= by default. I tried a build by disabling this optimization but that doesn'= t solved the problem. By disabling lto, the.llvm. are not seen in rus= tdoc binary but still the binaries are differed. I'll have to check with ll= vm community that how this hash depends/affects based on build-dir name/len= gth. Thanks, Sundeep K. --panb6GDXqgZdFmytDTSN Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 5, 2024 at 08:55 PM, Alexander Kanavin wrote:
After reading the issue and poking at the rustdoc binaries on m= y local disk, I think the key is in finding where those llvm.<hash> s= uffixes are generated and *how*. Something (presumably rust-llvm) puts them= there, so narrowing down to the point where that non-reproducible value is= decided would help a lot in finding out why it sometimes changes. It does = require navigating and reading a mountain of unfamiliar llvm code, this is = what makes the issue difficult.
The  .llvm.<hash> are generated by ThinLTO optimizations, and this is enabled by defaul= t. I tried a build by disabling this optimization but that doesn't solved t= he problem. By disabling lto, the .llvm.<hash> are not seen in rustdoc binary = but still the binaries are differed. I'll have to check with llvm community= that how this hash depends/affects based on build-dir name/length.
Thanks,
Sundeep K. --panb6GDXqgZdFmytDTSN--