On Thu, 14 Nov 2019 at 17:39, Keith Packard <kei...@keithp.com> wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > That defines the instruction sequence used to make a semihosting > > call, but not the specification of what the calls are: > > * what call numbers perform which functions > > * how arguments are passed to the call (registers? parameter > > blocks in memory? other?) > > * the semantics of each function supported (number of arguments, > > behaviour, error handling) > > > > That's really what I had in mind by the overall semihosting spec. > > There isn't anything more provided by the RISC-V foundation at this > point. I'm not sure what else they *should* provide as the goal is to > match the ARM design, which does specify all of the above.
This isn't obvious if you just say "semihosting". QEMU currently provides 'semihosting' ABIs for: * arm * lm32 * m68k * mips * nios2 * xtensa m68k and nios2 provide basically the same set of calls, but all the other architectures differe from each other. "Semihosting" just means "the concept of an ABI from guest to the debugger or emulator", not a particular ABI. The ARM semihosting ABI also has a number of warts which are basically historical legacy. With a clean sheet you get to avoid some of them. (Notably you could skip the whole 'negotiate presence of extensions' business by just getting those parts right from the start. Actually specifying errno values would also be sensible and is something the ARM spec sadly does not do and can't really at this point with multiple implementations in play.) thanks -- PMM
