https://patchew.org/QEMU/20190916141544.17540-1-peter.mayd...@linaro.org/
is a patchset which adds semihosting v2 support to QEMU. With those
patches and a guest binary which understands semihosting v2 and knows
how to probe for the existence of the EXIT_EXTENDED extension, arm guest
binaries will be able to pass a non-zero exit status.
** Changed in: qemu
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1216845
Title:
qemu-system-arm semihosting always calls exit(0)
Status in QEMU:
In Progress
Bug description:
In my embedded ARM project I have a bunch of unit tests that I run in
a POSIX synthetic environment, and, as usual for POSIX processes,
these tests return 0 for success and !=0 for error.
Now I expanded the testing environment to run some of these tests
compiled for ARM, under QEMU, with the tracing messages forwarded via
the semihosting API.
Up to now everything is fine with the emulation.
However I have a problem with passing the failure code back to the
operating system, to drive the continuous integration framework.
I checked the arm-semi.c code and for SYS_EXIT and I discovered that
the parameter passed is ignored and it always calls exit(0):
case SYS_EXIT:
gdb_exit(env, 0);
exit(0);
To solve my problem I temporarily made a patch, and for cases that
should return non zero codes, I call an unsupported BKPT instruction,
which makes QEMU abort, and pass an non zero code (1) back to the
operating system.
qemu: Unsupported SemiHosting SWI 0xf1
This kludge is more or less functional, but is quite inconvenient.
After checking the ARM manuals, I discovered that SYS_EXIT is not
standard, and the 0x18 code used for it originally was used for
angel_SWIreason_ReportException, which has a slightly different
purpose.
Now the question:
Would it be possible to no longer ignore the code passed to 0x18, and
if it is non zero, to call exit() with a different value?
The suggested rule would be:
if (code ==0 || code == 0x20026)
exit(0);
elif (code < 256)
exit(code);
else
exit(1);
The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I
understood it right, it means that the program terminated
successfully. If this is not true, it can be removed from the first
conditional statement.
What do you think? Can this be added to arm-semi.c?
Regards,
Liviu
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1216845/+subscriptions
