The semihosting v2 support went into QEMU in the 4.2 release, but I
forgot to close this bug...
** Changed in: qemu
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.ne
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
With the new 2.0 ARM semihosting ABI, there is an optional extension
SYS_EXIT_EXTENDED which can be used to implement returning a non-zero
exit code for 32-bit ARM programs:
https://developer.arm.com/docs/100863/latest/semihosting-operations
/sys_exit_extended-0x20#sh-ext-exit-extended
QEMU shoul
On 4 February 2015 at 15:56, Karl Zimmerman
wrote:
> Had a similar problem with my emulation environment. However, I did
> some inspection of the assembly code generated by newlib for ARM semi-
> hosting. While it initially appears that exit() and _exit() discard the
> status code, upon careful
Had a similar problem with my emulation environment. However, I did
some inspection of the assembly code generated by newlib for ARM semi-
hosting. While it initially appears that exit() and _exit() discard the
status code, upon careful inspection one finds that it is pushed on the
stack, with th
thank you for your suggestion.
as semihosting servers I use the j-link gdb server, openocd and qemu. if
I got it right, you suggest to modify all these servers to retrieve the
exit code from a specific location. as long as this is not documented in
the ARM manuals, I cannot recommend such a soluti
