qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 4/4] meson: Warn when TCI is selected but TCG backend is a


From: Stefan Weil
Subject: Re: [PATCH v4 4/4] meson: Warn when TCI is selected but TCG backend is available
Date: Tue, 26 Jan 2021 20:44:35 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

Am 26.01.21 um 18:24 schrieb Alex Bennée:
I'm going to go out on a limb and guess you have commit:

   23a77b2d18 (build-system: clean up TCG/TCI configury)

which temporarily has the effect of disabling TCI. See

   Subject: Re: [PATCH v4 1/4] configure: Fix --enable-tcg-interpreter
   From: Paolo Bonzini <pbonzini@redhat.com>
   Message-ID: <2b8b6291-b54c-b285-ae38-21f067a8497d@redhat.com>
   Date: Mon, 25 Jan 2021 17:36:42 +0100

with that fix fixed I see the same failures as Richard:

   ./qemu-arm ./tests/tcg/arm-linux-user/fcvt > /dev/null
   TODO ../../tcg/tci.c:614: tcg_qemu_tb_exec()
   ../../tcg/tci.c:614: tcg fatal error
   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
   fish: “./qemu-arm ./tests/tcg/arm-linu…” terminated by signal SIGSEGV 
(Address boundary error)

which does raise the question before today when was the last time anyone
attempted to run check-tcg on this?


Yes, I tested with latest git master and did not notice that --enable-tcg-interpreter was broken.

Paolo's patch fixed that.I could reproduce the fatal assertions which were all caused by the same missing TCG opcode implementation.

I have sent a trivial patch which adds that implementation and fixes all segmentation faults.


Daniel, regarding your comment: TCI has 100 % test coverage for the
productive code lines.
By what tests? The fact you don't hit asserts in your day to day testing
doesn't mean there are features missing that are easily tripped up or
that TCI got it right.


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`.


All code lines which were never tested raise an
assertion, so can easily be identified (and fixed as soon as there is a
test case which triggers such an assertion). The known deficits are
speed, missing TCG opcodes, unimplemented TCG opcodes because of missing
test cases and missing support for some host architectures.


As soon as I was aware of the new test cases, adding the missing TCG opcode implementation was not difficult.


Passing check-tcg would be a minimum for me.


It should pass now unless you get timeouts for some tests. Please tell me if more TODO assertions are triggered by new tests.

Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]