Hi, On Mon, Jan 09, 2017 at 05:31:37PM +0000, James Cowgill wrote: > On 06/01/17 00:51, Dmitry V. Levin wrote: > > On Tue, Jan 03, 2017 at 06:02:44PM +0000, James Cowgill wrote: > >> On 20/12/16 00:36, Steve McIntyre wrote: > >>> On Tue, Dec 20, 2016 at 03:16:17AM +0300, Dmitry V. Levin wrote: > >>>> On Tue, Dec 20, 2016 at 12:50:29AM +0100, Nahim El Atmani wrote: > >>>>> On Mon, 19 Dec 2016 18:30:29 +0000, Steve McIntyre wrote: > >>>>>> I'm seeing test suite failures on mips[1], mipsel[2] and mips64el[3] > >>>>>> on Debian machines. > >>>>>> > >>>>>> The 32-bit builds are both showing issues with fault injection. I > >>>>>> can't follow what the code is meant to be doing here, so no > >>>>>> ideas on what's wrong. :-( > >>>>> > >>>>> As Dmitry said earlier: > >>>>> > >>>>> On Tue, 15 Nov 2016 15:43:59 +0300, Dmitry V. Levin wrote: > >>>>>> Well, the mips kernel does not implement substitution of syscall > >>>>>> numbers > >>>>> > >>>>> So it looks like the test has failed to SKIP on this target. > >>>> > >>>> As I'm not 100% sure there is no kernel support for mips, I decided > >>>> not to skip the test on mips until somebody investigates. > >>> > >>> Ah, OK. James Cowgill is my friendly local mips expert - let's see > >>> what he thinks... :-) > >> > >> I've had a look and I think there is a kernel bug here - specifically > >> affecting 32-bit programs run on 64-bit kernels (like all the Debian > >> buildds and the porterbox are). An extra PTRACE_SYSCALL stop is > >> happening which confuses everything. I'll look some more tomorrow. > > > > Indeed, it seems to be a kernel bug in scall64-o32.S and scall64-n32.S. > > > > According to current arch/mips/kernel/scall64-o32.S:trace_a_syscall > > (the same applies to arch/mips/kernel/scall64-n32.S), > > > > if the syscall number after the first syscall_trace_enter call is out > > of range, there is a jump to not_o32_scall which in turn jumps to > > arch/mips/kernel/scall64-64.S:handle_sys64 (or to handle_sysn32 which > > then jumps on to handle_sys64). > > > > Handle_sys64, unsurprisingly, does all over again, starting with > > a syscall_trace_enter call, which appears to be the second one > > and causes that extra syscall stop you observe with 32-bit tracees > > running on 64-bit kernels. > > Just going through all the MIPS testsuite bugs again: > > fault_injection* > The kernel bug above (no patch yet).
I couldn't find an easy fix for this kernel bug. Any ideas? > readahead > glibc bug fixed in 2.25 > https://sourceware.org/bugzilla/show_bug.cgi?id=21026 I applied a workaround for this: v4.15-266-ge752ef6. > pwritev > I debugged this to an Octeon specific kernel bug in Octeon's optimized > copy_from_memory implementation :S I've sent a patch to the linux-mips > list to fix this. > https://www.linux-mips.org/archives/linux-mips/2017-01/msg00094.html Great. > newfstatat > Firstly we need to define TEST_BOGUS_STRUCT_STAT somewhere otherwise the > test just segfaults in glibc. Could you send a patch for this, please? > After that it suffers from the negative dates problem which happens when > glibc copies struct stat on mips n64. I thought I fixed this - did > something change? There was a big rework of struct stat{,64} decoding, see commit v4.13-80-ga7c4ee4. I reverted that workaround for mips n64 (commit v4.13-81-g6fc5338) as I believe it's no longer needed, otherwise other related tests would fail. -- ldv
pgpVYcrjWTtfY.pgp
Description: PGP signature
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
