From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 6A67C3858C50 for ; Tue, 12 Jul 2022 10:40:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6A67C3858C50 Received: by mail-oi1-x22b.google.com with SMTP id r82so9965553oig.2 for ; Tue, 12 Jul 2022 03:40:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=45N5rQfftwZCJg+niWxCIoiIJUc2tUcyevys9JjP1PA=; b=U7y+mNRj8KpJQ9hg+wCwv2aakXu2Xodz80ge/Ckt9cI/nf17fY9CW+lf/qY4DP48j4 NF33Fv9m0vCT3b92yzaXWtBciuQpaeQB9zd1PkVzGojBZ7A6D/b68BAFge6Hw1SuCywA zQA1zjFMhXWLi2kCIq1XdXpi+w0LGn0w0jNzGQgagVqSlYFbNK404v3Cf28CPcRxUjD3 Q+BaccJH0g9P4dNgEM5NrNejMxNWhsr0Y3Rw7UEiZob4Stde0q2hqcfi+dp+L7Y1XXLD VSnoy39dLJrmd60N0G/Ulma4gm+/3uWnOjyuwlu5bv2nSM54tt9DyHdcESWj7ezm8L++ azdA== X-Gm-Message-State: AJIora+wEy7IS6XkYJndgYKAO4bUu1QXb49yNCg0wZBOzI0zZeElkI1M 29cNJTQZN+wahTmCEn6vFO0iSWz8OgPGDA== X-Google-Smtp-Source: AGRyM1thQOXfq4gSiZTBhrCBvpAUI7AcnYjtuK3uTdbq8a+SMcI6uS/NKQG6+6zEAL3V9iQ8w0W7lQ== X-Received: by 2002:a54:478b:0:b0:339:e6d0:664c with SMTP id o11-20020a54478b000000b00339e6d0664cmr1391810oic.283.1657622433648; Tue, 12 Jul 2022 03:40:33 -0700 (PDT) Received: from [12.18.8.156] ([201.46.27.6]) by smtp.gmail.com with ESMTPSA id r2-20020acac102000000b0032e3cca8561sm3781939oif.21.2022.07.12.03.40.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 03:40:33 -0700 (PDT) Message-ID: <3a73adb0-5e98-30aa-bbfc-646e30ab4c47@linaro.org> Date: Tue, 12 Jul 2022 07:40:29 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 Subject: Re: Bug Report: ldd introduces non-deterministic behavior in subsequent piped commands Content-Language: en-US To: Florian Weimer , Adhemerval Zanella via Libc-help Cc: N References: <0672659a-10d8-99b5-5f76-cdd28a282eb8@gmail.com> <544CCC5B-009C-4E74-AB78-67CC28674C56@linaro.org> <87sfn71oh2.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87sfn71oh2.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 10:40:36 -0000 On 11/07/22 15:41, Florian Weimer wrote: > * Adhemerval Zanella via Libc-help: > >> Although I do not characterize this as a bug, since it represents the >> ELF objects are already being loaded by the kernel, it is already >> done since d7703d3176d225d5743b21811d888619eba39e82 (to be included >> in 2.36): >> >> $ LD_TRACE_LOADED_OBJECTS=1 ./elf/ld-linux-x86-64.so.2 /bin/true >> linux-vdso.so.1 => linux-vdso.so.1 (0x00007fff4c1d1000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7e75469000) >> /lib64/ld-linux-x86-64.so.2 => ./elf/ld-linux-x86-64.so.2 (0x00007f7e756ba000) >> >> Using LD_TRACE_LOADED_OBJECTS=2 also prints the binary itself: >> >> $ LD_TRACE_LOADED_OBJECTS=2 ./elf/ld-linux-x86-64.so.2 /bin/true >> /bin/true => /bin/true (0x00007f0aebc1c000) >> linux-vdso.so.1 => linux-vdso.so.1 (0x00007ffc0f9b3000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0aeb9d3000) >> /lib64/ld-linux-x86-64.so.2 => ./elf/ld-linux-x86-64.so.2 (0x00007f0aebc24000) >> >> And now that you brought it, I wonder if this would case some disruption. >> I think we might need to filter this out to keep the current lld behavior, >> I am not sure. > > Should we always print the soname on the LHS (except maybe when printing > the main executable)? /lib64/ld-linux-x86-64.so.2 is a bit of an > outlier because it's not the soname, but its default installation path. The LHS for loader does make sense if the loader is issued manually (as per testrun.sh for instance), although it is not usual. What does not make much sense is printing the vDSO path, but since the idea is keep all the entries in same format I don't see it as a deal breaker. I am more worried about the possible breakage of LD_TRACE_LOADED_OBJECTS consumers.