Stefan Weil <s...@weilnetz.de> writes:
> Am 26.01.21 um 23:39 schrieb Richard Henderson: > >> On 1/26/21 9:44 AM, Stefan Weil wrote: >>> I was not talking about the TODO assertions. When I wrote TCI, I only >>> enabled >>> and included code which was triggered by my testing - that's why I said the >>> productive code lines have 100 % test coverage. TODO assertions are not >>> productive code, but debug code which were made to detect new test cases. >>> They >>> were successful, too, because they were triggered by some tests in `make >>> check-tcg`. >> The TODO assertions are all bugs. >> >> Any *real* dead code detection should have been done in >> tcg/tci/tcg-target.c.inc. What's interpreted in tcg/tci.c should be exactly >> what is produced on the other side, and you are producing more than you are >> consuming. > > > Unless the TCG opcodes in tcg/tci/tcg-target.c.inc are used in real-live > scenarios, they are dead code, too. For example - debian-buster (arm64) running ffmpeg: alex.bennee@8cd150a4b35d:~/lsrc/qemu.git/builds/all.tci$ ./qemu-aarch64 /usr/bin/ffmpeg -i theora.mkv theora.webm TODO ../../tcg/tci.c:882: tcg_qemu_tb_exec() ../../tcg/tci.c:882: tcg fatal error qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (core dumped) > Writing a test case which produces them directly (not for some real > architecture) is not a real-live scenario. > > And the remaining TODO assertions are a good indicator that the current > tests are incomplete for native TCG because they obviously don't cover > all TCG opcodes. That's because check-tcg isn't a comprehensive test suite and expecting it to be misses the point of it. It was added to make it easy to add new test cases and remove some of the burden off maintainers having their own zoo of test binaries. It has slowly grown as directed test cases were written while bug hunting and sometimes when new features where added. It will never be a comprehensive exercising of the CPU emulation although some architectures have more coverage than others. For example MIPs has a bunch of ISA level tests as part of check-tcg but most of the ARM ISA validation is done externally using the RISU random instruction testing tool. Besides you've just argued writing a test case that targets missing functionality in TCI would somehow be cheating as it's not a "real-live" scenario. I don't mind either way - the fact that TCI is useful to people is cool and more power to them. But lets not pretend it is a fully functional and maintained backend because it has obviously got some major holes. If it ends up being a drag on efforts to maintain and improve the TCG then we have to question why we are keeping it in. Being able to run emulation on esoteric hardware without a real backend is a party trick at best. The other use-cases that have been mentioned could be solved with investing some effort in the rest of the TCG code. -- Alex Bennée