| Message ID | 878vyky0nc.fsf@firetop.home |
|---|---|
| State | New |
| Headers | show |
On Sun, 16 Jan 2011, Richard Sandiford wrote: > Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c > =================================================================== > --- gcc/testsuite/gcc.c-torture/execute/20101011-1.c 2011-01-16 21:32:28.000000000 +0000 > +++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c 2011-01-16 21:53:10.000000000 +0000 > @@ -18,6 +18,10 @@ > true of other bare-metal environments, so restrict the test to > systems that use the Linux kernel. */ > # define DO_TEST 0 > +#elif defined (__mips16) && defined(__linux__) > + /* Not all Linux kernels deal correctly the breakpoints generated by > + MIPS16 divisions by zero. They show up as a SIGTRAP instead. */ > +# define DO_TEST 0 > #else > # define DO_TEST 1 > #endif Hopefully this can be reenabled sometime in the future... And that's actually a good test too even as it is. If the kernel can't handle BREAK exceptions correctly, then chances are it doesn't handle other MIPS16 stuff either, making all the test results questionable in the first place. Maciej
"Maciej W. Rozycki" <macro@linux-mips.org> writes: > On Sun, 16 Jan 2011, Richard Sandiford wrote: >> Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c >> =================================================================== >> --- gcc/testsuite/gcc.c-torture/execute/20101011-1.c 2011-01-16 21:32:28.000000000 +0000 >> +++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c 2011-01-16 21:53:10.000000000 +0000 >> @@ -18,6 +18,10 @@ >> true of other bare-metal environments, so restrict the test to >> systems that use the Linux kernel. */ >> # define DO_TEST 0 >> +#elif defined (__mips16) && defined(__linux__) >> + /* Not all Linux kernels deal correctly the breakpoints generated by >> + MIPS16 divisions by zero. They show up as a SIGTRAP instead. */ >> +# define DO_TEST 0 >> #else >> # define DO_TEST 1 >> #endif > > Hopefully this can be reenabled sometime in the future... And that's > actually a good test too even as it is. If the kernel can't handle BREAK > exceptions correctly, then chances are it doesn't handle other MIPS16 > stuff either, making all the test results questionable in the first place. This is a compiler testcase, not a kernel testcase. And I don't agree that failure to handle division by zero traps correctly makes all the other GCC test results questionable. I'm confident that the testcase in its current form is still good enough to test what it was originally designed to test, even for MIPS. Richard
On Thu, 24 Feb 2011, Richard Sandiford wrote: > >> @@ -18,6 +18,10 @@ > >> true of other bare-metal environments, so restrict the test to > >> systems that use the Linux kernel. */ > >> # define DO_TEST 0 > >> +#elif defined (__mips16) && defined(__linux__) > >> + /* Not all Linux kernels deal correctly the breakpoints generated by > >> + MIPS16 divisions by zero. They show up as a SIGTRAP instead. */ > >> +# define DO_TEST 0 > >> #else > >> # define DO_TEST 1 > >> #endif > > > > Hopefully this can be reenabled sometime in the future... And that's > > actually a good test too even as it is. If the kernel can't handle BREAK > > exceptions correctly, then chances are it doesn't handle other MIPS16 > > stuff either, making all the test results questionable in the first place. > > This is a compiler testcase, not a kernel testcase. And I don't agree > that failure to handle division by zero traps correctly makes all the > other GCC test results questionable. Well, if the kernel does not have MIPS16 support implemented, then you cannot rely on correct execution of binaries in the face of hardware interrupts and other exceptions, although of course you may be lucky. There *is* knowledge about the ISA bit (or actually the expected lack of it) hardcoded in several places throughout the Linux kernel, although I am aware the number of such places has got limited over time (e.g. the FPU emulator does not rely on setting the LSB of the PC to trigger an (unaligned) address exception anymore). Of course if there actually is interest in supporting MIPS16 binaries under Linux, then whoever is interested will audit the kernel and clean up any such dependencies, but until then you rely on pure lack. And proper emulation of software-decoded instructions is certainly a good sign of good support. > I'm confident that the testcase in its current form is still good > enough to test what it was originally designed to test, even for MIPS. Obviously it does cover all the other configurations, no doubt here. Maciej
"Maciej W. Rozycki" <macro@linux-mips.org> writes: > On Thu, 24 Feb 2011, Richard Sandiford wrote: >> >> @@ -18,6 +18,10 @@ >> >> true of other bare-metal environments, so restrict the test to >> >> systems that use the Linux kernel. */ >> >> # define DO_TEST 0 >> >> +#elif defined (__mips16) && defined(__linux__) >> >> + /* Not all Linux kernels deal correctly the breakpoints generated by >> >> + MIPS16 divisions by zero. They show up as a SIGTRAP instead. */ >> >> +# define DO_TEST 0 >> >> #else >> >> # define DO_TEST 1 >> >> #endif >> > >> > Hopefully this can be reenabled sometime in the future... And that's >> > actually a good test too even as it is. If the kernel can't handle BREAK >> > exceptions correctly, then chances are it doesn't handle other MIPS16 >> > stuff either, making all the test results questionable in the first place. >> >> This is a compiler testcase, not a kernel testcase. And I don't agree >> that failure to handle division by zero traps correctly makes all the >> other GCC test results questionable. > > Well, if the kernel does not have MIPS16 support implemented, then you > cannot rely on correct execution of binaries in the face of hardware > interrupts and other exceptions, although of course you may be lucky. > There *is* knowledge about the ISA bit (or actually the expected lack of > it) hardcoded in several places throughout the Linux kernel, although I am > aware the number of such places has got limited over time (e.g. the FPU > emulator does not rely on setting the LSB of the PC to trigger an > (unaligned) address exception anymore). > > Of course if there actually is interest in supporting MIPS16 binaries > under Linux, then whoever is interested will audit the kernel and clean up > any such dependencies, but until then you rely on pure lack. And proper > emulation of software-decoded instructions is certainly a good sign of > good support. I was (and still am) interested in getting compiler support for MIPS16 glibc-based binaries working. I've found Linux to be in a good enough state that (in my last run a couple of weeks ago) there were no MIPS16 C and C++ execution failures over and above the "normal" o32 ones. You might call that pure luck, but it's certainly good enough for me. Obviously if someone interested in the Linux support wants to do the kind of audit that you suggest, then great. But I think the current situation is much better than you suggest. Richard
Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c =================================================================== --- gcc/testsuite/gcc.c-torture/execute/20101011-1.c 2011-01-16 21:32:28.000000000 +0000 +++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c 2011-01-16 21:53:10.000000000 +0000 @@ -18,6 +18,10 @@ true of other bare-metal environments, so restrict the test to systems that use the Linux kernel. */ # define DO_TEST 0 +#elif defined (__mips16) && defined(__linux__) + /* Not all Linux kernels deal correctly the breakpoints generated by + MIPS16 divisions by zero. They show up as a SIGTRAP instead. */ +# define DO_TEST 0 #else # define DO_TEST 1 #endif