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/gcc_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 QEMU app with the exit
code stored in 'r5'.
I've done essentially the same for 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
