On Tue, 5 Nov 2019 at 05:10, Keith Packard <kei...@keithp.com> wrote: > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > I'm going to push for somebody actually writing out a > > document and putting it somewhere that we can point to > > and say "that's the authoritative spec", please... > > it doesn't have to be a big formal thing, but I do > > think you want it written down, because the whole point > > is for multiple implementations and users to interoperate. > > That happened in June -- I was just looking at the wrong version of the > spec. In the current version, which can be found here: > > https://riscv.org/specifications/ > > The RISC-V Instruction Set Manual > Volume I: Unprivileged ISA > Document Version 20190608-Base-Ratified > > Section 2.8 says: > > Another use of EBREAK is to support “semihosting”, where the > execution environment includes a debugger that can provide > services over an alternate system call interface built around > the EBREAK instruction. Because the RISC-V base ISA does not > provide more than one EBREAK instruction, RISC-V semihosting > uses a special sequence of instructions to distinguish a > semihosting EBREAK from a debugger inserted EBREAK. > > slli x0, x0, 0x1f # Entry NOP > ebreak # Break to debugger > srai x0, x0, 7 # NOP encoding the semihosting call > number 7 > > Note that these three instructions must be 32-bit-wide > instructions, i.e., they mustn’t be among the compressed 16-bit > instructions described in Chapter 16. > > The shift NOP instructions are still considered available for > use as HINTS. > > Semihosting is a form of service call and would be more > naturally encoded as an ECALL using an existing ABI, but this > would require the debugger to be able to intercept ECALLs, which > is a newer addition to the debug standard. We intend to move > over to using ECALLs with a standard ABI, in which case, > semihosting can share a service ABI with an existing standard. > > We note that ARM processors have also moved to using SVC instead > of BKPT for semihosting calls in newer designs.
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. PS: the parenthetical about ARM semihosting at the bottom of the text you quote is wrong, incidentally. The traditional insn for semihosting on A-profile devices has always been SWI/SVC; it is BKPT only on M-profile devices; and the latest revision of the semihosting spec recommends the HLT instruction for both A- and M-. thanks -- PMM
