On Mon, Feb 13, 2017 at 04:47:05PM +0000, James Cowgill wrote: > Hi, > > > On 13/02/17 14:40, Dmitry V. Levin wrote: > > On Mon, Jan 09, 2017 at 08:54:52PM +0300, Dmitry V. Levin wrote: > >> 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? > > > > OK, there is not going to be any fix for this kernel bug in v4.10, > > so I'd rather disable scno tampering tests when MIPS ABI is o32 > > but the kernel is n64. > > > > Is there any simple way for MIPS o32 userspace to find out whether > > the kernel is not a native MIPS o32? Something less hackish > > than manually invoking a MIPS n64 syscall? > > uname -m is a bit less hackish: > > 32-bit kernel: $(uname -m) = mips > 64-bit kernel: $(uname -m) = mips64
No, it didn't work out, 64-bit kernel pretends it's mips: http://www.einval.com/debian/strace/build-logs/mipsel/2017-02-14-040242-log-eller-TESTFAIL.txt -- ldv
pgpxjFOG9Wj8Z.pgp
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
