Subject: Re: bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64

From: Bengt Richter <[email-masked]>
Date: Fri, 3 Sep 2021 18:53:35 +0200

On +2021-09-03 10:00:33 -0400, Simon South wrote:
> Bengt Richter <[email-masked]> writes:
> > A proper configurability, ISTM, would be preferable to any other form
> > of more general filtering.
> 
> I agree with you on the need to be cautious around modifying test cases
> but I'm not sure I follow you otherwise.  What would "proper
> configurability" look like in this case?
> 
> The change I'm proposing here narrows the two test cases so they test
> only what appears to have been intended, i.e. that strace can capture
> readlink(at) system calls and that it reports them in the format
> expected by the developers.  It does not affect other test cases or the
> test suite as a whole.
> 
> The obvious alternative would be to modify the test cases' expected
> output to match what is actually generated, but this could have the side
> effect of tying the package to Linux and perhaps to specific versions of
> glibc.

Well, that would be the point :)
I.e., to move the customizations into .conf files and out of test-suite sources.

> 
> That said I'm still not sure why this additional syscall is being made
> in the first place, only that it appears to originate from glibc's
> "_dl_get_origin" function[0].  If I build strace from source "manually"
> the tests complete fine without modification.  I presume the extra call
> has to do with the fact Guix builds strace inside a container; does
> anyone know how this could be affecting the way programs are loaded?
>

I did not realize there were mods to strace itself affecting this.
I thought it was about somehow filtering its output to fool tests, sorry.

With strace variants maybe "proper configurability"
should have to consider strace versions also, to tune test expectations ;/

> -- 
> Simon South
> [email-masked]
> 
> [0] See e.g. glibc's sysdeps/unix/sysv/linux/dl-origin.c for the x86-64
>     case, as well as "_dl_non_dynamic_init" in elf/dl-support.c, which
>     seems to be the only place it is called.

-- 
Regards,
Bengt Richter