Bug Report: ldd introduces non-deterministic behavior in subsequent piped commands

[Adhemerval Zanella Netto]

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.