Re: [PATCH v4] elf: Fix DFS sorting algorithm for LD_TRACE_LOADED_OBJECTS with missing libraries (BZ #28868)

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 04/03/2022 09:43, Andreas Schwab wrote:
> On Mär 04 2022, Adhemerval Zanella via Libc-alpha wrote:
> 
>> @@ -2725,3 +2735,50 @@ $(objpfx)tst-p_align3: $(objpfx)tst-p_alignmod3.so
>>  $(objpfx)tst-p_align3.out: tst-p_align3.sh $(objpfx)tst-p_align3
>>  	$(SHELL) $< $(common-objpfx) '$(test-program-prefix)'; \
>>  	$(evaluate-test)
>> +
>> +
>> +# Move the library to a folder so it can be selected by --library-path
>> +define libtracemod-mv
>> +  test -d $(objpfx)libtracemod$(1) || mkdir $(objpfx)libtracemod$(1)
> 
> You can use mkdir -p, which avoids any races.

Ok.

> 
>> +  test -f $(objpfx)libtracemod$(1).so \
>> +	  && mv $(objpfx)libtracemod$(1).so $(objpfx)libtracemod$(1)
> 
> This will result in a non-zero status if $(objpfx)libtracemod$(1).so
> doesn't exist, causing the command to fail.  It's also not race-free.

Right, but since $(objpfx)libtracemod$(1).so is a prerequisite I don't
see how the failure will happen.  How do you suggest to handle it?

> 
>> +define tst-trace-skeleton
>> +$(objpfx)tst-trace$(1).out: $(..)scripts/tst-ld-trace.py \
>> +			    $(objpfx)libtracemod1.so \
>> +			    libtracemod-mv \
>> +			    tst-trace$(1).exp
> 
> The dependency on the phony libtracemod-mv will cause the command to
> always be rerun.
> 

Thinking twice the phony does not seem the best option, I replaced with
a stamp file:

  $(objpfx)libtracemod-mv.stamp: $(objpfx)libtracemod1.so
          $(call libtracemod-mv,2)
          [...]
          touch $@

  $(objpfx)tst-trace$(1).out: $(..)scripts/tst-ld-trace.py \
                               $(objpfx)libtracemod-mv.stamp \
                               tst-trace$(1).exp

However even with this the rule seems to be rerun every time.  Any idea
on how to avoid it?