Spike(?) error codes

[Adrian Mcmenamin]

Is there a place I can go look for the meaning of Spike error codes?

I have some benchmarks (running on bare metal, so little/no library support) which do execute but return the message "*** FAILED *** (tohost = 1337)"

I can find the point in the disassembly where a0 is loaded with 1337 (which I assume is a sort of joke leet error code) but have not been able to find anything that matches even the "FAILED" string in the Spike sources (and certainly not in the benchmark sources - which should deliver no messages to stdout/stderr in any case).

Some of the benchmarks run fine, so I don't think it's a compiler error - and this message is spat out after around 400k of instructions are executed so it seems to be the result of a computation.

Adrian

[Christopher Celio]

Is there a place I can go look for the meaning of Spike error codes?

"*** FAILED *** (tohost = 1337)"

The error codes have nothing to do with spike, and are instead from the software. Spike is just printing what was given back to the testharness from the core via the tohost mechanism (aka, it prints the failure code the core gave it). I assume you're using the riscv-tests/benchmarks/common/syscalls.* code to provide some support while running bare metal? In that case, 1337 is purposefully designed to catch your eye and make you go digging further into your screwup (it's easy to "grep" for!).  =)

As I recall, 1337 in the bare metal benchmarks is for syscalls (or was it exceptions?) that are not supported.  An example scenario is executing an instruction unsupported by the core, which throws an exception, and when running bare metal, there is no emulation library to kick into.

-Chris

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAATR6d8rrwaFLbZ23-LF%2B5Z77RSK1_fU-ftmv2c%2BBYoXqj15nQ%40mail.gmail.com.

[Adrian Mcmenamin]

On 10 September 2016 at 22:16, Christopher Celio <ce...@eecs.berkeley.edu> wrote:

Is there a place I can go look for the meaning of Spike error codes?

"*** FAILED *** (tohost = 1337)"

The error codes have nothing to do with spike, and are instead from the software. Spike is just printing what was given back to the testharness from the core via the tohost mechanism (aka, it prints the failure code the core gave it). I assume you're using the riscv-tests/benchmarks/common/syscalls.* code to provide some support while running bare metal? In that case, 1337 is purposefully designed to catch your eye and make you go digging further into your screwup (it's easy to "grep" for!).  =)

As I recall, 1337 in the bare metal benchmarks is for syscalls (or was it exceptions?) that are not supported.  An example scenario is executing an instruction unsupported by the core, which throws an exception, and when running bare metal, there is no emulation library to kick into.

Thanks for the answer - you were correct: this comes from syscalls.c, which I had in a different directory and so wasn't included in my grep. D'uh!