Hi, On 14/02/17 09:27, Dmitry V. Levin wrote: > On Mon, Feb 13, 2017 at 04:47:05PM +0000, James Cowgill wrote: >> 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
Hmm and from the kernel source it looks like you cannot unset PER_LINUX32 once it's been set: http://lxr.free-electrons.com/source/arch/mips/kernel/linux32.c#L121 So I don't think there is any nice way to tell. James
signature.asc
Description: OpenPGP digital 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
