Re: [Qemu-devel] [PATCH] blogposts: add post about the new check-tcg infrastructure

[Alex Bennée]

Max Filippov <address@hidden> writes:

> On Thu, Jun 21, 2018 at 11:41 AM, Alex Bennée <address@hidden> wrote:
>> Signed-off-by: Alex Bennée <address@hidden>
>> ---
>>  _posts/2018-06-21-tcg-testing.md | 129 +++++++++++++++++++++++++++++++
>>  1 file changed, 129 insertions(+)
>>  create mode 100644 _posts/2018-06-21-tcg-testing.md
>>
>> diff --git a/_posts/2018-06-21-tcg-testing.md 
>> b/_posts/2018-06-21-tcg-testing.md
>
> [...]
>
>> +The `tests/tcg` directory still contains a number of source files we
>> +don't build. Notably the cris, lm32, mips, openrisc and xtensa targets have
>> +a set of tests that need a system emulator. Now we have the
>> +infrastructure for compiling I hope we can get support for system
>> +tests added fairly quickly. There will need to be some work to figure
>> +out a nice common way to pass results back to the build-system. For
>> +linux-user this is simple as all programs can simply return their exit
>> +code however for system emulation this is a little more involved.
>
> xtensa tests pass exit codes to the build system through semihosting calls.
> If any of them fails make check fails as well.

I've re-written that section as:

  The `tests/tcg` directory still contains a number of source files we
  don't build.

  The cris and openrisc directories contain user-space tests which just
  need the support of a toolchain and the relevant Makefile plumbing to
  be added.

  The lm32, mips and xtensa targets have a set of tests that need a
  system emulator. Aside from adding the compilers as docker images some
  additional work is needed to handle the differences between plain
  linux-user tests which can simply return an exit code to getting the
  results from a qemu-system emulation. Some architectures have
  semi-hosting support already for this while others report their test
  status over a simple serial link which will need to be parsed and
  handled in the `run-%:` test rule.

How is that?

Any chance you could look into what it would take to package up the
xtensa toolchain in a docker container? Are they simply tarballs of
binaries?

--
Alex Bennée