Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test case ? If all is Ok, execution and compilation shall ideally pass for the test cases. But I have noticed that there are some output pattern checks done in some test cases and this may fail since the output assembly is different, anyway I shall give it a try and send you the results with the new options.
On Tue, Mar 13, 2018 at 8:42 AM, Michael Eager <ea...@eagerm.com> wrote: > On 03/12/18 23:10, Andrew Sadek wrote: > >> _Command for running testsuite:_ >> >> /make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu >> CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h >> -L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group >> -mlittle-endian' "/ >> >> _Quick Details:_ >> 1) common.h: Here I define 'STACK_SIZE' with (0x4000) as it's used in >> some test cases. >> 2) -L ..... /lib: it contains libm, libc in little endian since we use >> 'qemu-system-microblazeel', and libxil which is the libgloss + some >> additional features (read, write, inbyte, outbyte) built with Xilinx SDK. >> >> _mb-gcc command example from gcc.log:_ >> >> Testing execute/va-arg-15.c, -O1 >> doing compile >> Executing on host://home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx- >> elf/build/build-cc-gcc-final/gcc/xgcc -B/home/andrew/gcc_workspace/g >> cc_orig/microblaze-xilinx-elf/build/build-cc-gcc-final/gcc/ >> /home/andrew/gcc_workspace/gcc_orig/microblaze-xilinx-elf/ >> src/gcc/gcc/testsuite/gcc.c-torture/execute/va-arg-15.c -include >> /home/andrew/qemu/common.h -L/home/andrew/qemu/lib >> -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian >> -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -w >> -T/home/andrew/qemu/qemu/microblazeel-softmmu/xilinx.ld -lm -o >> ./va-arg-15.exe (timeout = 300)/ >> > > OK. This shows that the patch does not cause regressions when the new > options are not used. That is good. > > Please run the same regression test with the new PIC options. Ideally you > should have the same results. > > > >> >> >> On Mon, Mar 12, 2018 at 4:30 PM, Michael Eager <ea...@eagerm.com <mailto: >> ea...@eagerm.com>> wrote: >> >> On 03/12/18 06:19, Andrew Sadek wrote: >> >> >> >> On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager <ea...@eagerm.com >> <mailto:ea...@eagerm.com> <mailto:ea...@eagerm.com >> >> <mailto:ea...@eagerm.com>>> wrote: >> >> On 03/02/2018 08:12 AM, Andrew Sadek wrote: >> >> Hello Michael, >> >> I tried running the whole GCC test suite on the current >> head >> (without my patch) along with 'microblaze-qemu' but I >> have the >> following problems: >> >> 1) The test is hanging at >> 'gcc.c-torture/string-large-1.c' , the >> gcc is making a 100% CPU usage and the machine stucks. >> I tried compiling the file alone, it generated a couple >> of >> warnings than it hangs. >> warning: '__builtin_memchr' specified size >> 4294967295 exceeds >> maximum object size 2147483647 [-Wstringop-overflow=] >> vp1 = __builtin_memchr (a, b, SIZE1); >> >> Is it a bug? Is there something wrong with my >> configuration ? >> GCC configured with options : --with-newlib >> --enable-threads=no >> --disable-shared --with-pkgversion='crosstool-NG >> crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit >> --disable-libgomp --disable-libmudflap --disable-libmpx >> --disable-libssp --disable-libquadmath >> --disable-libquadmath-support --enable-lto >> --with-host-libstdcxx='-static-libgcc >> -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' >> --enable-target-optspace >> --disable-nls --enable-multiarch --enable-languages=c,c++ >> >> >> Your configuration is more complex than my hard-metal >> target version, >> but it looks reasonable. >> >> The problem with string-large-1.c does appear to be a bug. >> You can >> add a line to the test case which will mark it as known >> failure for MB: >> >> /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */ >> >> (I have not tested this, but it should work. Compare with >> other >> xfail's.) >> >> >> Problem that the whole compile package is invoked with '-w' >> which inhibits all warnings and overrides ' -Werror' as well as >> ' -Wfatal-errors' . >> As a result, the warning message does not appear when running >> compile.exp. Any suggestions ? Do I remove the '-w' ? >> >> >> >> 2) For running QEMU, I have no problem with elf >> execution. But I >> do not know how to auto terminate the QEMU itself as >> it remains >> up even after program execution. >> Is there some command to be passed to QEMU in order >> make system >> shut down after program termination with its exit code ? >> >> >> Yes, this is a problem. For other targets using QEMU I >> have added dummy >> HLT instructions to terminate QEMU, or used a wrapper >> around QEMU which >> sets breakpoints at exit (or _exit) and stops the simulator >> when hit. >> >> If you are running Linux on QEMU, instead of using QEMU's >> built-in gdb >> interface you might use the Linux system as the target for >> the test >> suite, running gdbserver on the target. >> >> >> I have finally managed to fully run QEMU with test suite but had >> to make a local modification in the QEMU code itself. >> In the translate function, I make a check if "bri 0" is reached >> which is the '_exit'. Then, abort the QE >> <https://maps.google.com/?q=h+is+the+'_exit'.+Then,+abort+the+QE&entry=gmail&source=g>MU >> app with the exit >> code stored in 'r5'. >> >> >> I've done essentially the same for >> <https://maps.google.com/?q=I've+done+essentially+the+same+for+&entry=gmail&source=g>other >> targets. >> >> Here are the results below: >> _Without Patch:_ >> === gcc Summary === >> >> # of expected passes90776 >> # of unexpected failures 1317 >> # of unexpected successes3 >> # of expected failures207 >> # of unresolved testcases115 >> # of unsupported tests2828 >> >> _With Patch and after adding my test case:_ >> === gcc Summary === >> >> # of expected passes90790 >> # of unexpected failures1317 >> # of unexpected successes3 >> # of expected failures207 >> # of unresolved testcases115 >> # of unsupported tests2828 >> >> >> This appears to be reasonable results. It appears that there are no >> regressions. >> >> Please send me the mb-gcc command line options for both of these >> test runs. >> >> >> >> >> -- Michael Eager ea...@eagerm.com <mailto:ea...@eagerm.com> >> 1960 Park Blvd., Palo Alto, CA 94306 >> >> >> >> >> -- >> >> Andrew >> > > -- > Michael Eager ea...@eagerm.com > 1960 Park Blvd., Palo Alto, CA 94306 > -- Andrew