Re: [Qemu-arm] Regression tests for Assembly libraries for Cortex-M: More recent qemu versions core-dump or fail with warnings

[Peter Maydell]

On Thu, 25 Apr 2019 at 23:33, "Björn Haase" <address@hidden> wrote:
>
> Hello to all,
>
> I'd appreciate some advice on how to
> - simulate a ARM Cortex-M4 system with large amount of RAM
> - together with semihosting (stdin, stdout and files) on the host CPU.
>
> The background of my question is a bit different from the conventional QEMU 
> use-case for full-system simulation:
>
> I am working on CC0 crypto libraries for the Arm Cortex-M series (see e.g. 
> https://github.com/BjoernMHaase/fe25519). There is a lot of assembly 
> optimization and assembly code-generators behind the scenes which need 
> extensive tests. I'd like to publish my code together with a regression test 
> library running on Qemu (specifically regarding the asm stuff). The 
> regression tests best have access to files and need to be executed without 
> the code-size-restriction and memory constraints of the tiny embedded targets 
> (which might not even allow for stl containers, e.g.).
>
> The problem is that the regression suite code is too big to fit onto any 
> embedded target. I.e. I'd need to simulate a cortex-m4 system with, e.g. 256 
> MByte RAM and with file access using the semihosting support. So just running 
> on the embedded target is not an option :-(. The use case is, thus, not to 
> simulate real-world CPUs but to simulate CPUs that are not available in the 
> real world.

This is unfortunate, because one of the general principles
we have with QEMU models is "emulate the real world hardware,
don't make things up that don't exist". Heading down the
"make stuff up" path has got us into awkward hard-to-maintain
corners in the past.

> With the older versions of QEMU, I succeeded with using
>
> qemu-system-arm -nographic -monitor null -serial null -semihosting -cpu 
> cortex-m4 -m 256M -M integratorcp -kernel ./test_naclM4

This only ever worked by pure fluke and because your test
code never needed to interact with interrupts or access
any memory-mapped system registers. The integratorcp board
is an A-profile board which does not have an NVIC (which
in QEMU's implementation means that none of the memory
mapped system registers will be present and anything to
do with interrupt handling is likely to crash).
We tightened up our error-checking so that we no longer let
users accidentally create some of these command line
combinations which work only in very restricted cases.

> Unfortunately the more recent versions of QEMU either core-dump or give 
> warnings.
> On Qemo 4.0 I get the result "qemu-system-arm: This board cannot be used with 
> Cortex-M CPUs".
> I did some attempts using e.g. the lm3s811evb targets. However, I constantly 
> get failures such as
>
> "qemu-system-arm: Trying to execute code outside RAM or ROM"
>
> most surely since qemu checks for the limitations of this specific 
> microcontroller memory sizes, which I want to exceed intentionally!

Typically the thing that limits the RAM size is the
physical address map of the board -- if the board
doesn't provide lots of RAM then QEMU won't model it.
The lm3s811evb boards are particularly small-ram setups.
The various mps2 boards have 16MB (they are cortex-m3
or cortex-m33, rather than -m4, but we don't have
any -m4 boards at the moment.)

> Also I believe that semihosting will not be supported on any of the native 
> cortex-m machines? Any advice would be very appreciated.

All the cortex-m systems support semihosting. (Note
that the ABI for M-profile semihosting is not quite
the same as the A-profile ABI -- it uses a breakpoint
insn, rather than an SVC insn.) You need to enable
it with the -semihosting option, and you can't use
it from non-privileged code (this is the same as the
A-profile semihosting).

> - Is there some documentation on how to add a new machine to the qemu code? I 
> did not actually find the place where e.g. the lm3s811evb configuration is 
> stored within the source trees.

There is no documentation -- the best thing to do
is look at existing code (preferably a newer board
model, as we have a lot of old legacy code that's
not written to current best practice). Board models
for Arm systems are in hw/arm/; the mps2 boards are
fairly new and a good example. If you're going to
hack QEMU for this you might be able to find a place
in the MPS2's memory map to put a larger lump of RAM,
rather than writing a whole new board model.

thanks
-- PMM