with current CVS, `make check-sim` fails for cr16 targets due to linker errors. an example from the log: Testing addb.cgs on machine cr16. Executing on host: .../gas/as-new .../sim/testsuite/sim/cr16/addb.cgs -I.../sim/testsuite/sim/cr16 -o addb.cgs.o (timeout = 300) spawn .../gas/as-new .../sim/testsuite/sim/cr16/addb.cgs -I.../sim/testsuite/sim/cr16 -o addb.cgs.o Executing on host: .../ld/ld-new addb.cgs.o -o addb.cgs.x (timeout = 300) .../ld/ld-new addb.cgs.o -o addb.cgs.x .../ld/ld-new: warning: cannot find entry symbol _start; defaulting to 0000000000000002 linker output is: .../ld/ld-new: warning: cannot find entry symbol _start; defaulting to 0000000000000002 .../ld/ld-new: warning: cannot find entry symbol _start; defaulting to 0000000000000002 FAIL: cr16 addb.cgs (linking) all i did was checkout cvs and run: ./configure --target=cr16-elf make all-sim make check-sim
It *could* be that the test-suite assumes a specific dejagnu board-file is used, e.g. "make check-sim RUNTESTFLAGS=--target_board=cr16-sim", one which would add some necessary linker option. But, there's no dejagnu board-file generally accessible; none even at the master branch of the savannah dejagnu git, so the cr16 sim testsuite should cope without it.
The master branch has been updated by Michael Frysinger <vapier@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4daf7a7c3a8404d8be973702ffe00541f71606a4 commit 4daf7a7c3a8404d8be973702ffe00541f71606a4 Author: Mike Frysinger <vapier@gentoo.org> Date: Sun Mar 29 21:00:20 2015 -0400 sim: cr16: add _start symbol to tests [BZ #12385] The current cr16 testsuite sets up _START, but the linker looks for the _start symbol. Add the latter as an alias to the former.
i've fixed the linking error, but the tests all fail during execution now: spawn /usr/local/src/gnu/gdb/build/build-cr16/sim/testsuite/../cr16/run addb.cgs.x ^@^@^@^@^@output: pattern: pass FAIL: cr16 addb.cgs (execution) this is because the sim is writing out \0\0\0\0\0. looking at the objdump and the runtime shows the data addresses *look* correct, but the cr16 sim doesn't seem to have its memory in sync with the ELF. the sim_cr16_translate_addr and similar funcs do weird things to the address and i can't figure out why it's all broken.
oddly, my conversion of the cr16 sim to the nrun framework also fixed the output. this makes me think the memory handling is really wonky in this sim. but the tests pass now, and i'm not doing anymore immediate work on it, so i guess that's good enough ...