Re: Role of qemu-arm

["Alex Bennée" <alex.bennee@linaro.org>]

vincent Dupaquis <v.dupaquis@trusted-objects.com> writes:

> The libraries in this case do not make any interaction with I/O. We take
> control over them through GDB to be able to run them & test them.

So you could instead use a semihosting wrapper and use SYS_REPORTEXC to
report a pass/fail back to whatever invoked QEMU. If you look at
tests/tcg/arm/semihosting.c it can actually be built with:

  semihosting-arm: LDFLAGS+=-nostdlib -N -static

And you get a libc free executable with about ~30 insns that can be
invoked by qemu-arm.

> They can be linked into a ELF binary (indeed this is how we test them,
> we link them with a dummy binary and take control over it using the
> debug interface).
>
> Regading the priviledged instructions, I do not understand the question,
> we only use available core instructions (I do not remember about
> priviledged instructions in Cortex-Mx.

Things like accessing system control registers and the like.

>
> Le 24/06/2020 à 12:14, Alex Bennée a écrit :
>> vincent Dupaquis <v.dupaquis@trusted-objects.com> writes:
>>
>>> Indeed, for us it has an interest, as we do libraries running on
>>> cortex-Mx cores. We are not linked to any specific board and can run
>>> on any.
>> Do the libraries use any privileged instructions?
>> How do they interact with I/O?
>> Can they be linked into an ELF binary?
>>
>>> Currently, we are using a basic board (the netduino2), and do not make
>>> use of any peripherals (that's the goal of our project, being able to be
>>> used on any board, with the right core). We do not even use the IT
>>> controller.
>>>
>>> You are right to say that there is no need of having 'plain cpu'
>>> emulation, as long as you can use any existing simulated board model.
>>> So, as long as there is
>>>
>>> By the way, my original question was on the usage of qemu-arm, and I
>>> have my response now :) It has no interest for cortex-Mx devices.
>> So I believe some of the gcc m-profile test suite runs under qemu-arm
>> with semihosting for this reason. You may need to wrap a little test
>> harness around your libraries to get this to work though.
>>
>>> Best regards,
>>>
>>> Vincent.
>>>
>>> Le 22/06/2020 à 15:43, Peter Maydell a écrit :
>>>> On Mon, 22 Jun 2020 at 14:03, vincent Dupaquis
>>>> <v.dupaquis@trusted-objects.com> wrote:
>>>>>     It is a shame, so I suppose I'll have to stay with my emulation
>>>>> using netduino2 or so ...
>>>>>
>>>>>     That was the reason why I tried to use qem-arm, which is probably
>>>>> crashing because what you just suggested.
>>>> qemu-arm is for "I'm a linux userspace binary"; if your code is
>>>> a userspace binary then you can use it...
>>>>
>>>>>     Is there a way of pointing-out the interest for the feature ?
>>>> I'm afraid we don't support or have any plan to support
>>>> "just run a CPU, no peripherals". I don't think there's much
>>>> utility in it -- M-profile needs the interrupt controller,
>>>> almost any setup wants to have a UART for I/O, and you need
>>>> some actual RAM, which then leaves you with the question of
>>>> what address to put the RAM at. At that point you're not
>>>> really "just a CPU", you're "a minimalist board that doesn't
>>>> correspond to any real hardware". We've found from experience
>>>> that emulating things which don't correspond to something
>>>> in the real world is not really maintainable and supportable
>>>> in the long term.
>>>>
>>>> If your code will genuinely run on any M-profile board,
>>>> just pick whichever one seems most useful and ignore
>>>> the devices you don't need to use. (I like the mps2-an385,
>>>> it has a bit more RAM than most.)
>>>>
>>>> thanks
>>>> -- PMM
>>


-- 
Alex Bennée