Running programs on aarch64 simulator

Joel Sherrill joel@rtems.org
Mon May 11 18:30:36 GMT 2020


On Mon, May 11, 2020 at 12:59 PM Jim Wilson <jimw@sifive.com> wrote:

> On Mon, May 11, 2020 at 7:41 AM Joel Sherrill <joel@rtems.org> wrote:
> > I'm trying to build one that will run on the simulator. I haven't
> managed to
> > do that yet. :(
>
> You can find the answer in dejagnu.  See baseboards/aarch64-sim.exp
> which uses -specs=rdimon.specs.
>
> The aarch64 gdb sim is incomplete by the way.  ARM won't let ARM
> engineers contribute to it because of IP concerns.  I did some work on
> it when I was at Linaro, but there are still a number of instructions
> that are missing or implemented wrong.  I got the gcc testsuite
> failures down to about 1200 before I left Linaro.  I don't test it
> anymore, so I don't know the current state.  I would suggest using
> qemu instead unless you want to fix simulator bugs.
>

Thanks Jim.  That is very helpful.  I managed to get an executable
to run with aarch64-elf-run and traced it failing quite early at
newlib-cygwin/libgloss/aarch64/syscalls.c:287 doing something with
the semi-hosting extensions.  Have you seen this simulator work
well enough recently to run the gcc testsuite?

It sounds like for my purposes of where to start development of an
aarch64 RTEMS port, this is one time we need to skip the gdb simulator
step. The gdb simulators are just so nice to work through basic issues
like context switching, stack setup, etc. Since we would only need C
with basic integer operations and enough FPU support to context
switch the FPU, 1200 gcc failures may not have been a stopper.

I know that it has limited use since there are so many alternatives
and embedded folks are just going to use CMSIS or some OS support.
I was just hoping to use it to add to the free RTOS list. Guess we will
start with Qemu unless someone has some brilliant idea that makes
this work.

Thanks again Jim.

--joel

>
> Jim
>


More information about the Gdb mailing list