make check failing on times with -m32

Steve McIntyre steve at
Tue Apr 19 14:53:00 UTC 2016

On Mon, Apr 18, 2016 at 05:42:22AM +0300, Dmitry V. Levin wrote:
>On Mon, Apr 18, 2016 at 12:09:55AM +0100, Steve McIntyre wrote:
>> On Thu, Jan 14, 2016 at 02:31:01AM +0000, Steve McIntyre wrote:
>> >
>> >Coincidentally, I've just been doing exactly that already this
>> >evening. I'm in the middle of hacking on a script to run tests
>> >periodically on the various Debian porter boxes, so should be able to
>> >give you some better and more timely results in future too.
>> >
>> >Results from VERBOSE=1 shortly.
>> Wow, this has taken a while to get back to - sorry... :-(
>> However, I now have stuff in place to run a HEAD build automatically
>> for all the Debian (release) arches nightly and push logs out. See
>> for the logs, split by architecture. Please let me know if this is
>> useful - I'm open to suggestions for changes.
>Some simple ideas:
>- keep git quiet: specify -q option to git clone;
>- print key information about the build environment, e.g.
>uname -rm, version of kernel headers, libc version, gcc version.

ACK, done now - see

as an example.

>> I still have outstanding failures for:
>> mips/mipsel: prctl-seccomp-filter-v
>This is somewhat similar to lseek/llseek case: libc does something
>on its own that has to be filtered out.  Should be fixed now.
>> 	     prctl-seccomp-strict
>I'm aware of kernel issues with both prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT)
>and seccomp(SECCOMP_SET_MODE_STRICT) on x32 and mips, but it looks strange
>when seccomp works while prctl fails.


>> 	     pselect6 *
>Should be fixed now.
>> 	     rt_sigsuspend
>This might be a big endian bug in the test.
>It passes on parisc, though.

But I'm seeing on both mips and mipsel (i.e. both big- and
little-endian). I'll take a look later on.

>> mips64el:    bpf
>> 	     execveat-v
>> 	     execveat
>> 	     fcntl
>> 	     fstat
>> 	     lstat
>> 	     membarrier
>> 	     mlock2
>> 	     newfstatat
>> 	     pselect6 *
>> 	     stat
>> 	     userfaultfd
>Something is wrong with strace support on this architecture if it cannot
>decode syscall numbers properly.

Right. I'll see if the mips porters can help here.

Steve McIntyre, Cambridge, UK.                                steve at
"Because heaters aren't purple!" -- Catherine Pitt

More information about the Strace-devel mailing list