From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 79EA23852C5C for ; Mon, 21 Nov 2022 14:51:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79EA23852C5C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x536.google.com with SMTP id v8so5554150edi.3 for ; Mon, 21 Nov 2022 06:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=y/V7sBZq7i5wIqz2W530yaBgaoI3k7fd6LOo82SRWWo=; b=pRalYNpG9905q/fWDoTSCVbfX9znc+Np/AWgktKYQATNSe0/wj6XF0+x61iHSZsP7Z RwTmY+eX/vaXGPj6/d4r8rAHqAK7d24JhoVQLLa4LMED6dfYWt8hKLRleBUJTIugzUQ+ Ty7tNcAIfoYdRbfP7hw9p2YWnT2FdQtm4csrvluRg77VNgJoEQA3pRVEf6kilKaIHtz7 pRx5EuOnh7LcjWvyLHr7lP4ngdx3up6chCG9U10ezPfDyLd57Qkasd+9UJ3evXZke31S 7GDwq+9HQtph4ZYRQ3MXwdC7kFqni1Iae+UnZA8oalaeOT5AlwMx3mzVqHpLbky9TnZJ I2+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=y/V7sBZq7i5wIqz2W530yaBgaoI3k7fd6LOo82SRWWo=; b=zQwEzC9aO+ZmG2f/GPI7/RnksfVTTJQOMXrNYyaf6+0hmmLQCdxgly5Qyt7EL7vCUC /0Cn+62KYwO5semROt+jw7nXRzvFCtFzi1t88TgSo9AWqJmh0NWP3iw76TKml4+eWrd9 U2oRjporQalk7w+m6/sQNGdJAnoJ1OUBYrW16ZSEAFot5MWfBpcYQEeVGhWAQPkWQHxV QQyRnTRJkhMPf2Y7R3yHa/OlMVut09veuoAWahs1E9ssy4isRV+Yjr7MYpUF5XeH/ssC gcc4843+XEC8Yngn6mGugghdRXroGvjycQbgOXK0xe7bHjNzagStYY0Fb45oskcTT8dO AnUg== X-Gm-Message-State: ANoB5pmfPdaH369ShLAsNl7htTGBJgiTwQoc3yhiiZVb+LxZzA8+yAwi Iua2tqNjKKcROLQ+s9NCpzVP4ZIXnA895pZE2j2RSd6i X-Google-Smtp-Source: AA0mqf7ui3Drr5XiXeo4aLL2Lo+Lue66/Qg6OBGlZW/4AAWJDVaeycfWgktvhcwQXN/TqQbAU7fIxgm1UAqyqcqHQjo= X-Received: by 2002:a05:6402:c6:b0:468:3d69:ace0 with SMTP id i6-20020a05640200c600b004683d69ace0mr16613320edu.356.1669042291441; Mon, 21 Nov 2022 06:51:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Kacvinsky Date: Mon, 21 Nov 2022 09:51:20 -0500 Message-ID: Subject: Re: Question about readelf output from shared library built with lld, gold, and bfd linkers To: Binutils Content-Type: multipart/alternative; boundary="000000000000e5833b05edfc3047" X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: --000000000000e5833b05edfc3047 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 21, 2022 at 9:14 AM Nick Clifton wrote: > Hi Tom, > > > Isee the following output from readelf for the lld, gold and bfd linkers > > (binutils 2.39, lld 14.0.6) > > To be clear - this is not a readelf problem. It is showing you the correct > results. It is the fact that the three linkers are not producing identical > output and instead showing slight variations in their layout of the linked > binary that is bothering you, yes ? > It's not bothering me so much as I was wondering if this would point to an issue with slow start up times. Reading your reply in totality, I now see this should not make a difference. > In general variations in the layout like this should not make any > difference > to the program#s startup time. There might - possibly - be variations in > performance due to affects like cache misses and the like, but this is hard > to quantify in isolation. > I didn't stop to think about caching and the like for relocations at start up. I was testing with the perf tool and LD_DEBUG=statistics to see how much time was spent in start up by symbols/relocations. Results varied from run to run, so I can now see how caching may play into this. > Output below. Notice how the ordering is different in each case. The > > interesting thing about this is, and why I am looking at various > > differences between object code linked by these three linkers, is that I > am > > trying to track down why startup times are slower due to relocations > (based > > on the perf tool output). Would any of these differences make, well, a > > difference in startup time? > > I don't think so. The number of relocations is the same, so the amount > of start up time spent resolving them should effectively be the same as > well. > > I assume that you have compared started up times when linking with "-z now" > vs "-z lazy" ? > I thought -z lazy was the default, and that if you wanted the equivalent of LD_BIND_NOW=1 on the command line, then one would use -z now. We don't want the latter, we already spawn enough processes that -z now would slow things down even more. I can try with -z lazy and report back. Thanks for the input, Tom --000000000000e5833b05edfc3047--