Trap semihosting ability

[LeeMooreImperas]

Hi Andrew (et al) Apologies in advance if this has already been asked, I could find no reference. Does spike have a similar facility to the arm angel traps for printing messages ? in particular we would like to be able to have a string in memory, then to be able to execute a trap instruction to cause the string to be printed by the simulator

in ARM the Angel SemiHost allows the following (pseudo code) mv r10

svc 123456 // Simulator prints content of pointer r10

There may be something similar in the Proxy Kernel, if so I could not find a document that described such a feature

Many thanks in advance Lee

[aswaterman]

Spike has a similar mechanism. The front-end server polls a memory location called tohost, then services system calls on behalf of a proxy kernel (pk) that runs on the target machine. The target machine code is here: https://github.com/riscv/riscv-pk/blob/master/machine/htif.c

[mwachs5]

Very timely question! We're also working on standardizing the scheme for using ebreak (with a magic value in mscratch) to run semihosted system calls. This will replace the polled memory location scheme when an external debugger is attached, and will allow OpenOCD/GDB/other external debuggers to perform these types of calls.

[jstraus59]

Thanks for the info - are there any public details available yet about the standard scheme for using ebreak/mscratch for semihosted system calls you mentioned? If not, any idea what time frame this might become available?

[mwachs5]

We will write up the concluded scheme and add it to the riscv/riscv-debug-spec repo shortly (as a markdown file, not to the spec itself). I’ll try to get this done today and send the link.

Megan

On Fri, Dec 8, 2017 at 03:33 Jim Straus notifications@github.com wrote:

Thanks for the info - are there any public details available yet about the standard scheme for using ebreak/mscratch for semihosted system calls you mentioned? If not, any idea what time frame this might become available?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-sim/issues/155#issuecomment-350242468, or mute the thread https://github.com/notifications/unsubscribe-auth/ARCAJDStVkVr9T15pyKi1SVo-svVjiPBks5s-R5-gaJpZM4QfQco .

-- Megan A. Wachs Engineer | SiFive, Inc 1875 South Grant Street Suite 600 San Mateo, CA 94402 megan@sifive.com

[mwachs5]

I summarized the email thread as a note on the Debug Spec: https://github.com/riscv/riscv-debug-spec/blob/b1fe84715270233f61ade78190e418db559ac010/EBREAK.md

Happy for feedback.

On Fri, Dec 8, 2017 at 5:26 AM, Megan Wachs megan@sifive.com wrote:

We will write up the concluded scheme and add it to the riscv/riscv-debug-spec repo shortly (as a markdown file, not to the spec itself). I’ll try to get this done today and send the link.

Megan

On Fri, Dec 8, 2017 at 03:33 Jim Straus notifications@github.com wrote:

Thanks for the info - are there any public details available yet about the standard scheme for using ebreak/mscratch for semihosted system calls you mentioned? If not, any idea what time frame this might become available?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-sim/issues/155#issuecomment-350242468, or mute the thread https://github.com/notifications/unsubscribe-auth/ARCAJDStVkVr9T15pyKi1SVo-svVjiPBks5s-R5-gaJpZM4QfQco .

-- Megan A. Wachs Engineer | SiFive, Inc 1875 South Grant Street Suite 600 San Mateo, CA 94402 megan@sifive.com

-- Megan A. Wachs Engineer | SiFive, Inc 1875 South Grant Street Suite 600 San Mateo, CA 94402 megan@sifive.com

[jstraus59]

Thanks very much for posting the description of the proposed replacement for the Host/Target Interface (HTIF) that is being phased out.

One comment would be that there is nothing explicitly defining the end of the arguments - would it make sense to encode the number of words in the argument list into the <protocol> word?

I would be interested to hear if anyone is looking to add support for this to Spike. (It looks to me like this would require changes to the Proxy Kernel and Frontend Server as well.)

Thanks

Jim Straus Imperas

[mwachs5]

Thanks for the feedback @jstraus59. WRT encoding the number of arguments, that should be encapsulated by the protocol itself. For example, the Linux Syscall API specifies how arguments are passed in registers. The semihosting protocol specifies that some arguments are in registers, and some are in memory pointed to by a value in one of the registers. I'm not sure that additional memory words would need to be included in the program stream other than the protocol type. Probably in the proposal document we should include a bit more information (links at least) to the definitions of the protocols.