make check failing on times with -m32
Steve McIntyre
steve at einval.com
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
>>
>> http://www.einval.com/debian/strace/build-logs/
>>
>> 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
http://www.einval.com/debian/strace/build-logs/armel/2016-04-19-140437-log-abel-SUCCESS.txt
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.
Yup.
>> 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 einval.com
"Because heaters aren't purple!" -- Catherine Pitt
More information about the Strace-devel
mailing list