| Message ID | 5559FEBF.7000804@arm.com |
|---|---|
| State | New |
| Headers | show |
On May 18, 2015, at 8:01 AM, Alan Lawrence <alan.lawrence@arm.com> wrote: > Simulators such as qemu report the presence of fork (it's in glibc) but generally do not support synchronization primitives between threads, so any tests using fork are unreliable. Hum, I have a simulator (binutils/sim) that has fork. All those tests pass for me. They seem to be reliable for me. I didn’t do anything special as I recall. ? I did add enough libc (aka newlib) to bootstrap gcc, which maybe is slightly more than some do, but, existence of additional libraries shouldn’t change it much. To the extent it does, it should be easy to notice any extra required libraries directly. If a qmu bug or design deficiency, do you have a pointer to the reported bug or the design where they talk about tit. Remember, the point of the test suite is to find bugs to be fixed. Papering over bugs by turning it off, is fine, but, we should have named bug reports that when fixed, cause us to go back and turn back on those that were turned off. > This patch disables the subset of such tests that identify themselves using dg-require-fork. > > At present, such tests are limited to (a) gcc.dg/torture/ftrapv-1.c. and (b) some tests in the 27_io section of the libstdc++ testsuite, listed below. Further patches can add dg-require-fork to the many other tests that call fork(). > > Cross-tested on aarch64-none-linux-gnu using qemu, with these tests becoming UNSUPPORTED: > > (gcc) > gcc.dg/torture/ftrapv-1.c So, I reviewed this test case. What about it doesn’t work? Kinda simple and small, easy to understand. > Is this patch OK for trunk? No. Let’s talk about it before turning off a to of test cases.
On 18 May 2015 at 20:25, Mike Stump <mikestump@comcast.net> wrote: > On May 18, 2015, at 8:01 AM, Alan Lawrence <alan.lawrence@arm.com> wrote: >> Simulators such as qemu report the presence of fork (it's in glibc) but generally do not support synchronization primitives between threads, so any tests using fork are unreliable. > > Hum, I have a simulator (binutils/sim) that has fork. All those tests pass for me. They seem to be reliable for me. I didn’t do anything special as I recall. ? Thanks for having a look at this problem. I thought about this a while ago, and was wondering whether the guard shouldn't be "are we using qemu?". Indeed as Mike, other simulators might support fork and threads quite well. > > I did add enough libc (aka newlib) to bootstrap gcc, which maybe is slightly more than some do, but, existence of additional libraries shouldn’t change it much. To the extent it does, it should be easy to notice any extra required libraries directly. > > If a qmu bug or design deficiency, do you have a pointer to the reported bug or the design where they talk about tit. I believe qemu broken support for threads is a well-known issue. For instance: https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02156.html > Remember, the point of the test suite is to find bugs to be fixed. Papering over bugs by turning it off, is fine, but, we should have named bug reports that when fixed, cause us to go back and turn back on those that were turned off. > >> This patch disables the subset of such tests that identify themselves using dg-require-fork. >> >> At present, such tests are limited to (a) gcc.dg/torture/ftrapv-1.c. and (b) some tests in the 27_io section of the libstdc++ testsuite, listed below. Further patches can add dg-require-fork to the many other tests that call fork(). >> >> Cross-tested on aarch64-none-linux-gnu using qemu, with these tests becoming UNSUPPORTED: >> >> (gcc) >> gcc.dg/torture/ftrapv-1.c > > So, I reviewed this test case. What about it doesn’t work? Kinda simple and small, easy to understand. > >> Is this patch OK for trunk? > > No. Let’s talk about it before turning off a to of test cases.
Christophe Lyon wrote: > On 18 May 2015 at 20:25, Mike Stump <mikestump@comcast.net> wrote: >> On May 18, 2015, at 8:01 AM, Alan Lawrence <alan.lawrence@arm.com> wrote: >>> Simulators such as qemu report the presence of fork (it's in glibc) but generally do not support synchronization primitives between threads, so any tests using fork are unreliable. >> Hum, I have a simulator (binutils/sim) that has fork. All those tests pass for me. They seem to be reliable for me. I didn’t do anything special as I recall. ? > > Thanks for having a look at this problem. > I thought about this a while ago, and was wondering whether the guard > shouldn't be "are we using qemu?". Indeed as Mike, other simulators > might support fork and threads quite well. Indeed they might. Is there a reasonable way to detect qemu? Or some acceptable mechanism to look for it, or tell the testsuite we are running under qemu? --Alan
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index f632d00..0ffd35c 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -1781,6 +1781,10 @@ proc check_function_available { function } { # Returns true iff "fork" is available on the target system. proc check_fork_available {} { + if { [check_effective_target_simulator] } { + # Most simulators do not properly support multithreading + return 0 + } return [check_function_available "fork"] }