On 09/20/14 08:52, Chen Gang wrote:
Thank you very much for your attachments, it is very useful to me!
I tried testsuite for microblaze cross target on x86_64 host, it says
OK ("echo $? == 0"), but I am not quite sure about it (I still doubt
that my configuration is incorrect), please help check, thanks.
Welcome to the joys of DejaGNU. Configuration can be confusing.
As you can see, the return code is not useful.
dejagnu configuration:
cp xmd.exp /usr/local/share/dejagnu/config/
cp microblaze-xilinx-gdb.exp /usr/local/share/dejagn/baseboards/
vi microblaze-xilinx-gdb.exp
"s/mc_gcc/microblaze\-gchen\-linux\-gcc/g"
gcc operation:
../gcc/configure --target=microblaze-gchen-linux --disable-nls
--enable-languages=c --disable-threads --disable-shared \
--without-headers --disable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic
make
make -k check-gcc
RUNTESTFLAGS="--target_board=microblaze-xilinx-gdb/-mno-xl-soft-mul/-mxl-barrel-shift/-mcpu=v6.00.a"
Check whether these compiler options are being passed to mb-gcc. There is a
line in my microblaze-xilinx-gdb.exp which sets CFLAGS:
set_board_info cflags "-mcpu=v4.00.b -mno-xl-soft-mul -mxl-barrel-shift"
This is likely overriding any options passed to runtest.
Make sure that the options match the features of your target board. You might
not need any options for your initial tests.
Make sure that the correct flags are being passed to the linker.
Add "-v" or "-v -v" to RUNTESTFLAGS so that the gcc.log file gives useful info.
You might want to limit the number of tests run until you get problems worked
out:
make check-gcc RUNTESTFLAGS="execute.exp -v -v
--target_board=microblaze-xilinx-gdb"
This will run only the gcc.c-torture/execute/execute.exp tests.
gcc result:
=== gcc Summary ===
# of expected passes 48408
# of unexpected failures 17253
# of unexpected successes 1
# of expected failures 97
# of unresolved testcases 16570
# of unsupported tests 1854
/upstream/build-gcc/gcc/xgcc version 5.0.0 20140920 (experimental) (GCC)
Look at gcc.sum and gcc.log to find out what is causing the large number of
unexpected failures. A large number of unresolved test cases often means that
the compiler returned an error.
--
Michael Eager ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
