From: "Alex Bennée" <alex.bennee@linaro.org>
To: Claudio Fontana <cfontana@suse.de>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: check-tcg HOWTO?
Date: Mon, 11 Jan 2021 13:35:27 +0000 [thread overview]
Message-ID: <8735z7pnzv.fsf@linaro.org> (raw)
In-Reply-To: <1301fc86-b356-b4a8-42c1-bf7705419a5e@suse.de>
Claudio Fontana <cfontana@suse.de> writes:
> Hi Alex,
>
> happy new year,
>
> I am trying to get check-tcg to run reliably,
> as I am doing some substantial refactoring of tcg cpu operations, so I need to verify that TCG is fine.
>
> This is an overall getting started question, is there a how-to on how
> to use check-tcg and how to fix things when things don't go smoothly?
Not really but I could certainly add something. Generally I just run the
tests manually in gdb when I'm trying to debug stuff.
> I get different results on different machines for check-tcg, although the runs are containerized,
> on one machine the tests for aarch64 tcg are SKIPPED completely (so no
> errors),
The compiles *may* be containerized - the runs are always in your host
environment. It's one of the reasons the binaries are built as static
images so you don't need to mess about with dynamic linking and
libraries.
The only reason some tests get skipped is if you have a locally
installed cross compiler which doesn't support some architecture
features (e.g. CROSS_CC_HAS_SVE).
> on the other machine I get:
>
> qemu-system-aarch64: terminating on signal 15 from pid 18583 (timeout)
> qemu-system-aarch64: terminating on signal 15 from pid 18584 (timeout)
> qemu-system-aarch64: terminating on signal 15 from pid 18585 (timeout)
> make[2]: *** [../Makefile.target:162: run-hello] Error 124
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [../Makefile.target:162: run-pauth-3] Error 124
> make[2]: *** [../Makefile.target:162: run-memory] Error 124
Given it's timing out on hello I guess it's the shutdown deadlocking.
Running with V=1 will give you the command line but the semihosting
config is setup for redirect. So I usually build my own command line. e.g.:
./qemu-system-aarch64 -monitor none -display none \
-chardev stdio,id=output \
-M virt -cpu max -display none \
-semihosting-config enable=on,target=native,chardev=output \
-kernel tests/tcg/aarch64-softmmu/hello
There is nothing particularly special apart from making sure semihosting
is wired up for the output. Apart from some special cases like
test-mmap-XXXX most tests don't take any arguments.
>
> Both are configured with
>
> configure --enable-tcg
>
> Anything more than V=1 to get more output?
The output is normally dumped in $TESTNAME.out in the appropriate
$BUILDDIR/tests/tcg/$TARGET/ directory.
> How do I debug and get logs and cores out of containers?
As I mentioned above the tests are not run in containers, just the
compiles (if local compilers are missing).
>
> in tests/tcg/ there is:
>
> a README (with no hint unfortunately) ,
Woefully out of date I'm afraid. What docs we have are in docs/devel/testing.rst
> Makefile.qemu
Links into the main tests/Makefile.include - invoked for each target
> Makefile.prereqs
This ensures docker images are built (if required) for each set of tests.
> Makefile.target
This is the main (rather simple) makefile which provides the build and
run targets. You can run directly if you are in the right build dir, eg:
13:58:10 [alex@zen:~/l/q/b/a/t/t/aarch64-softmmu] |✔ + pwd
/home/alex/lsrc/qemu.git/builds/arm.all/tests/tcg/aarch64-softmmu
13:58:57 [alex@zen:~/l/q/b/a/t/t/aarch64-softmmu] |✔ +
make -f ~/lsrc/qemu.git/tests/tcg/Makefile.target TARGET="aarch64-softmmu" SRC_PATH="/home/alex/lsrc/qemu.git" run
But TBH this is functionally equivalent to calling:
make run-tcg-tests-aarch64-softmmu
in your main build directory.
> There are a bunch of variables in these files, which seem to be
> possible to configure, am I expected to set some of those?
Not really. Most of the magic variables from:
tests/tcg/config-$TARGET.mak
which is built by tests/tcg/configure.sh during the configure step.
> I think that it would be beneficial to have either more documentation
> or more immediately actionable information out of make check failures;
V=1 should show the command lines run and then you should be able to run
the tests directly yourself.
> Any help you could give me to make some progess?
Hope that helps.
>
> Thanks,
>
> Claudio
--
Alex Bennée
next prev parent reply other threads:[~2021-01-11 14:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 9:32 check-tcg errors (build-user, build-user-plugins) again Claudio Fontana
2020-12-02 11:16 ` Alex Bennée
2020-12-02 11:25 ` Claudio Fontana
2020-12-02 12:52 ` Alex Bennée
2020-12-02 14:24 ` Claudio Fontana
2020-12-02 14:25 ` Philippe Mathieu-Daudé
2021-01-10 21:17 ` check-tcg HOWTO? Claudio Fontana
2021-01-11 13:35 ` Alex Bennée [this message]
2021-01-11 14:47 ` Claudio Fontana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735z7pnzv.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cfontana@suse.de \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.