riscv-software-src / riscv-isa-sim Goto Github PK
View Code? Open in Web Editor NEWSpike, a RISC-V ISA Simulator
License: Other
Spike, a RISC-V ISA Simulator
License: Other
I updated the latest version and run spike simulator but --dc does not work. Has it become obsolete?
I am having a problem building the toolchain.
`[promach@localhost riscv-tools]$ ./build.sh
Starting RISC-V Toolchain build process
Removing existing riscv-fesvr/build directory
Configuring project riscv-fesvr
Building project riscv-fesvr
Installing project riscv-fesvr
Removing existing riscv-isa-sim/build directory
Configuring project riscv-isa-sim
Building project riscv-isa-sim
../spike_main/disasm.cc: In constructor ‘disassembler_t::disassembler_t(int)’:
../spike_main/disasm.cc:257:1: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
disassembler_t::disassembler_t(int xlen)
^~~~~~~~~~~~~~
../riscv/gdbserver.cc: In member function ‘virtual bool halt_op_t::perform_step(unsigned int)’:
../riscv/gdbserver.cc:352:9: error: statement will never be executed [-Werror=switch-unreachable]
gs.tselect_valid = false;
^~
cc1plus: all warnings being treated as errors
make: *** [Makefile:319: gdbserver.o] Error 1
[promach@localhost riscv-tools]$ `
I have googled but no-one has the same error. I suppose -Werror is not encouraged in release code, https://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror/ or am I missing something ?
My system configurations are as follows:
Arch Linux, gcc (GCC) 7.1.1 20170528 , GNU ld (GNU Binutils) 2.28.0.20170506
Hi, is the spike updated to the latest spec?
I found out that the ecall will still trap to H mode.
https://github.com/riscv/riscv-isa-sim/blob/5762bedab3a671ddfd279737d370533f31ed979e/riscv/insns/ecall.h
I use riscv tools version: 886d8131dbd23533fb04d2d76a80be21d5f9ee7a and riscv-isa-sim version: 53d74f4
First I compile hello.c
with -g
to hello.rv
:
$ riscv64-unknown-elf-gcc -g hello.c -o hello.rv
Then I follow README https://github.com/riscv/riscv-isa-sim#debugging-with-gdb in one shell run:
$ spike --gdb-port 9824 pk hello.rv
It quickly prints "hello, word!"
So when I in a second shell I do that:
$riscv64-unknown-elf-gdb hello.rv
(gdb) target remote localhost:9824
It returns "localhost:9824: Connection timed out."
By the way, can I use rocket-chip/emulator with riscv-gdb like the way spike do so?
Hi folks,
I was wondering if someone is already working on adding basic block vector generation for simpoint flow so that I can collaborate. If not I will be happy to work on adding this feature into Spike. If you think there's something better out there than using simpoint, let me know!
The last commit a95b44df9d142a49f3e1bfe4a60d259ed41ca247 seemed to have broken the simulator for me. Now when building riscv-isa-sim (or the entire riscv-tools) I get a huge amount of errors that all go something like this:
ui64_to_f64.o: In function `softfloat_shortShiftRightJam128':
ui64_to_f64.c:(.text+0x180): multiple definition of `softfloat_shortShiftRightJam128'
f32_add.o:f32_add.c:(.text+0x180): first defined here
ui64_to_f64.o: In function `softfloat_shortShiftRightJam128Extra':
ui64_to_f64.c:(.text+0x1c0): multiple definition of `softfloat_shortShiftRightJam128Extra'
f32_add.o:f32_add.c:(.text+0x1c0): first defined here
ui64_to_f64.o: In function `softfloat_shiftRightJam64Extra':
ui64_to_f64.c:(.text+0x210): multiple definition of `softfloat_shiftRightJam64Extra'
f32_add.o:f32_add.c:(.text+0x210): first defined here
When reverting to bea283531abfd013811e83c75ff6189a0d9b3075
it builds fine.
I'm building on Fedora 23 and I'm just following the instructions in the Readme. So I'm not doing anything special. Just running
git submodule update --init --recursive
export RISCV=/opt/riscv/
./build.sh
And when it gets to the part where it builds riscv-isa-sim, the errors I pasted above come up. Same happens if I go to riscv-isa-sim/build and try to make it manually from there.
If I revert before that commit, I can boot SMP enabled linux with spike fine.
Compiling on Mac OS X 10.11 results in the following error:
g++ -fPIC -MMD -MP -Wall -Wno-unused -g -O2 -std=c++11 -DPREFIX=\"/usr/local\" -Werror -I. -I. -I./riscv -I./dummy_rocc -I./softfloat -I./spike_main ./riscv/insn_template.h -o insn_template.h.gch
clang: error: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated
make: *** [insn_template.h.gch] Error 1
This is because a C header is being pre-compiled with the C++ compiler, something Clang does not support.
Hello!
We are getting a segmentation fault when trying to simulate bbl in recent versions of this repository.
In particular, we are using commit 75f2a05df9cdff6f3faba748065b3184b9f01b01
and, after some debugging, we could isolate the segmentation fault in the line 174 in file ../riscv/mmu.h
.
The corresponding code is as follows:
inline icache_entry_t* refill_icache(reg_t addr, icache_entry_t* entry)
{
auto tlb_entry = translate_insn_addr(addr);
insn_bits_t insn = *(uint16_t*)(tlb_entry.host_offset + addr); // <---- This is line 174!
int length = insn_length(insn);
if (likely(length == 4)) {
insn |= (insn_bits_t)*(const int16_t*)translate_insn_addr_to_host(addr + 2) << 16;
} else if (length == 2) {
insn = (int16_t)insn;
} else if (length == 6) {
insn |= (insn_bits_t)*(const int16_t*)translate_insn_addr_to_host(addr + 4) << 32;
insn |= (insn_bits_t)*(const uint16_t*)translate_insn_addr_to_host(addr + 2) << 16;
} else {
static_assert(sizeof(insn_bits_t) == 8, "insn_bits_t must be uint64_t");
insn |= (insn_bits_t)*(const int16_t*)translate_insn_addr_to_host(addr + 6) << 48;
insn |= (insn_bits_t)*(const uint16_t*)translate_insn_addr_to_host(addr + 4) << 32;
insn |= (insn_bits_t)*(const uint16_t*)translate_insn_addr_to_host(addr + 2) << 16;
}
insn_fetch_t fetch = {proc->decode_insn(insn), insn};
entry->tag = addr;
entry->data = fetch;
reg_t paddr = tlb_entry.target_offset + addr;;
if (tracer.interested_in_range(paddr, paddr + 1, FETCH)) {
entry->tag = -1;
tracer.trace(paddr, length, FETCH);
}
return entry;
}
We have also tried commit 63c98b41ae2d36808ebbb57e7f8e871ba247d444
, where the segfault doesn't occur anymore. However, we could see how spike was stuck in that code region ignoring the previous segfault.
I want to simulate a bare metal code on spike, which is using memory mapped I/O. Is there a way to add an I/O memory region to spike and then read/write to it from host or GDB?
The RISCV ISA spec (linked to from http://riscv.org/download.html) says that return values go into registers x16-x17 (v0-v1), yet these registers don't exist in riscv/regnames.cc
. They used to, but commit 992205c changed them to match the 'new' ABI.
What is this new ABI exactly?
Hi,
I think a command that disassembles n instructions at a given memory locations would be useful.
Users who want to do that need to first read the memory location with mem
and then feed the lower half of the printed 64-bit value into spike-dasm
.
Following the instructions on http://riscv.org/download.html#tab_isa-sim to simulate a new instruction, I always run into a build error:
make: *** No rule to make target insns_ut/ut_beq.h', needed by
ut_beq.cc`. Stop.
I've installed riscv-isa-sim through the risc-v tools, have setup the prefix at $RISCV properly, I have not touched ut_beq and I followed step 3 by running ./build-spike-only.sh in riscv-tools.
Is there anything else I can add?
Hi,
I noticed (by manual inspection) that the code at riscv/sim.cc, line 152 will not work on big-endian machines. The uint32_t
words in reset_vec
are at first stored in host-endianness, then added to a std::vector
, and finally added to a rom_device_t
, both of which doesn't affect the endianness. RISC-V instructions must always be encoded in little-endian.
Although big-endian machines are increasingly rare, it's nicer to stay compatible with them.
Hi,
I followed the instructions for the installation and even if the --with-fesrv option is used (the library is found by the configure step), the path for the fesrv include files is not added to the g++ command line.
I need to do:
CPPFLAGS=-I$(RISCV)/include make
to get a successful compilation
The OS X build breaks partway through due to the new commit 71d04ec with the following error:
In file included from ../riscv/processor.cc:566:
./insn_list.h:1:17: error: expected ';' at end of declaration
DEFINE_INSN(add addi addiw addw amoadd_d amoadd_w amoand_d amoand_w amomax_d amomaxu_d amom...
^
../riscv/processor.cc:565:25: note: expanded from macro 'DEFINE_INSN'
REGISTER_INSN(this, name, opcodes[#name].first, opcodes[#name].second)
^
../riscv/processor.h:141:23: note: expanded from macro 'REGISTER_INSN'
extern reg_t rv32_##name(processor_t*, insn_t, reg_t); \
^
It seems like this may be caused by a difference in GNU sed and BSD sed. I have gsed installed and changing riscv.mk fixes this bug, but it would be great to not have gsed be a dependence.
tnewsome@debian-lap:~/SiFive/riscv-tools/riscv-isa-sim$ make
make: *** No rule to make target 'riscv/devicetree.h', needed by 'all'. Stop.
Is this a file you forgot to commit?
autoconf on RHEL6 fails with some m4_macro errors. The fix is to swap the position of two lines in configure.ac
Should be
AC_INIT(proj_name,proj_version,proj_maintainer,proj_abbreviation)
AC_LANG_CPLUSPLUS
instead of
AC_LANG_CPLUSPLUS
AC_INIT(proj_name,proj_version,proj_maintainer,proj_abbreviation)
Help message for option with values should be improved to specify all available values. Example:
--isa= RISC-V ISA string [default RV64IMAFDC]
I don't get what are all available.
From a fresh clone, following the directions:
make
...
g++ -fPIC -MMD -MP -I/opt/riscv/include -Wall -Wno-unused -g -O2 -std=c++11 -DPREFIX=\"/opt/riscv\" -Werror -I. -I.. -I../riscv -I../dummy_rocc -I../softfloat -I../spike_main -c ../spike_main/spike.cc
../spike_main/spike.cc: In function ‘int main(int, char**)’:
../spike_main/spike.cc:81:9: error: cannot declare variable ‘s’ to be of abstract type ‘sim_t’
sim_t s(isa, nprocs, mem_mb, halted, htif_args);
^
In file included from ../spike_main/spike.cc:3:0:
../riscv/sim.h:19:7: note: because the following virtual functions are pure within ‘sim_t’:
class sim_t : public htif_t
^
In file included from ../riscv/sim.h:9:0,
from ../spike_main/spike.cc:3:
/opt/riscv/include/fesvr/htif.h:39:19: note: virtual ssize_t htif_t::read(void*, size_t)
virtual ssize_t read(void* buf, size_t max_size) = 0;
^
/opt/riscv/include/fesvr/htif.h:40:19: note: virtual ssize_t htif_t::write(const void*, size_t)
virtual ssize_t write(const void* buf, size_t size) = 0;
^
Makefile:320: recipe for target 'spike.o' failed
make: *** [spike.o] Error 1
Using the following commands:
riscv64-unknown-elf-gcc -nostdlib -nostartfiles -Tlink.ld -m32 -o inst inst.s
spike --isa=RV32I -d inst
and then inside spike any of these:
pc 0
reg 0
mem 200
the values are displayed as 64 bit values (16 hex digits).
Is there a way to make spike simulate a 32 bit ISA with 32 bit pc, 32 bit registers and memory content displayed as 32 bit words?
Hi!
I tried to execute spike this way by navigating to the folder the executable is in:
cd ~/riscv-tools/riscv-isa-sim/build
./spike
I get this error message:
./spike: error while loading shared libraries: libriscv.so: cannot open shared object file: No such file or directory
It is significant that the file it claims to not find is in the same directory as the spike executable (in the build directory) - any help?
Since Spike is the main reference implementation of RISC-V, I think it should be flexible and easy to understand. Since we have qemu support for faster simulation, I think we can afford some loss of performance in favor of configurability and cleanliness.
Here are some of the things I had in mind (I've already done some of these, and I'll have them in a fork soon):
There are some pieces of code in Spike that are obviously tuned for performance (sometimes very cleverly), but I think since we have qemu as a faster simulator, I think we can pivot Spike towards flexibility and cleanliness to benefit the RISC-V community. What do you all think? If you agree, I would be happy to send some pull requests and finish up some of the work I was doing towards these goals.
edit: I pressed enter too soon (github needs an undo button like gmail) and posted this before I finished it. Sorry if you got an e-mail with random bits of stream of consciousness about Spike and Qemu.
Hi, I encountered this problem while debugging coreboot, which doesn't use the HTIF.
If a program doesn't provide the tohost
ELF symbol, spike will execute 5000 instructions and then hang in a loop without executing any more instructions. I tested this with spike f5ecf65 and riscvarchive/riscv-fesvr@916191caf3.
One easy way to proproduce this bug is to:
spike -l pk ./program
to verify that execution doesn't stoppk
into the current directorytohost
string in pk and patch it to something else (like nohost
)spike -l ./pk ./program |& tee trace-log
; observe that execution stops at some pointwc -l trace-log
and observe that 5000 instructions have been executedI haven't fully debugged it, but I've seen the following happening:
sim_t::run()
calls step(INTERLEAVE)
, INTERLEAVE
is defined as 5000sim_t::step(n)
simulates n
instrucions, does some bookkeeping and finally calls htif->tick()
htif_isasim_t::tick()
calls tick_once()
tick_once()
calls htif_pthread_t::recv
which calls recv_nonblocking
recv_nonblocking
doesn't find any data, so it calls host.switch_to()
htif_t::run()
It might not be related to this problem, but I noticed that both spike and libfesvr register their own handlers for SIGINT. As signal handlers don't automatically stack, this is probably a bad idea.
Issues when calling make result in errors:
error: 'CAUSE_MISALIGNED_FETCH' was not declared in this scope
error: 'CAUSE_FAULT_FETCH' was not declared in this scope
and about 10 others. Does this imply the install went awry? RISCV tools test seems to imply it is working properly.
riscv-isa-sim · (master) ★ ⟩ make
g++ -L. -Wl,-rpath,/usr/local/lib -o spike spike.o -lspike -lriscv -lsoftfloat -ldl -lpthread -lfesvr
/usr/bin/ld: cannot open output file spike: Is a directory
collect2: error: ld returned 1 exit status
Makefile:314: recipe for target 'spike' failed
make: *** [spike] Error 1
When compiling with clang under OS X the following warning is generated:
g++ -fPIC -MMD -MP -I/usr/local/riscv/include -Wall -Wno-unused -O2 -std=c++11 -DPREFIX="/usr/local/riscv" -I. -I../riscv -I../hwacha -I../dummy_rocc -I../softfloat -I../spike_main -c ../riscv/interactive.cc
../riscv/interactive.cc:186:14: warning: if statement has empty body
[-Wempty-body]
if (0) ;
^
../riscv/interactive.cc:186:14: note: put the semicolon on a separate line to
silence this warning
I would try to fix this but I'm not sure what the code in interactive.cc is attempting to do or what optimization it is leveraging.
I custom two csr (mbase,mbound) in spike projectfor Mbb policy which present on riscv-privileged-v1.9.1 specification.
My step is as follow:
1.add "mbase" and "mbound" in "parse-opcodes" file "riscv-opcode" project and run "make install"
2.in mstatus_init function ,"minit.c" file pk project, add "write_csr(mbound, ms);" to test if it works
when I compile pk project ,gcc failed and notify as follow:
../machine/minit.c: Assembler messages:
../machine/minit.c:25: Error: Instruction csrw requires absolute expression
Any test or benchmark fails at start with error trap_store_access_fault
.
any-bit pk.
Why spike can deny storing io?
Latest pull at the time of issue (db6051f)
I noticed that, while CSR_TIME
and CSR_STIME
are redirected to CSR_MTIME
, CSR_MTIME
is not implemented, resulting in an "Illegal Instruction" exception everytime one of these CSRs is used. Although bbl seems to work around the lack of mtime
somehow, it would be nice to have support for it in spike.
When I run spike --isa=RV32IM -H --gdb-port=7777
and after connecting with gdb I run info registers
Spike dies with the the error message
gdbserver code died: handle_register_read
gdb displays the following
ra 0x0000000000000000 0
sp 0x8000000000000000 -9223372036854775808
gp 0x0000000000000000 0
tp 0x0000000000000000 0
t0 0x0000000000000000 0
t1 0x0000000000000000 0
t2 0x0000000000000000 0
fp 0x0000000000000000 0
s1 0x0000000000000000 0
a0 0x0000000000000000 0
a1 0x0000000000000000 0
a2 0x0000000000000000 0
a3 0x0000000000000000 0
a4 0x0000000000000000 0
a5 0x0000000000000000 0
Remote connection closed
I think gdb is trying to read 64* 32 bits of registers rather than 32*32 bits like it should.
To test Boot ROM images (at least to some limited degree), it would be useful to be able to load files at some common positions in the address space (e.g. at the start), without first having to build an ELF file.
Are there any plans to implement such a feature?
Hi,
spike
and spike-dasm
e977e22 disassemble 0x00000000 as addi s0, sp, 0
, which is wrong in two ways:
00
, so it would be an RVC instruction. One can see in spike's instruction trace mode that it is decoded as 32 bits.0000
is defined as an invalid instruction in the RVC spec 1.9.Interestingly, when executing a 00000000
word in spike, an illegal instruction trap is generated.
Hi,
When I try to use Spike to run with GDB for single-step mode, I found the execution sequence is not expected, and one instruction is lost.
If I run spike with the isa-test rv32uc-p-rvc (from the riscv-tests/isa directory), I can see the instruction trace is like this:
core 0: 0xffffffff800000b0 (0x34129073) csrw mepc, t0
core 0: 0xffffffff800000b4 (0xf1402573) csrr a0, mhartid
core 0: 0xffffffff800000b8 (0x30200073) mret
core 0: 0x00000000800000bc (0x00200e13) li t3, 2 //<---------------------------------------> This instruction
core 0: 0xffffffff800000c0 (0x29a00593) li a1, 666
core 0: 0xffffffff800000c4 (0x00100613) li a2, 1
But when I run this test with GDB in single-step-mode, I can see the trace is like this:
0x800000ac in reset_vector ()
(gdb) ni
0x800000b0 in reset_vector ()
(gdb) ni
0x800000b4 in reset_vector ()
(gdb) ni
0x800000b8 in reset_vector ()
(gdb) ni
0x800000c0 in reset_vector ()//<------------------> We can see after the 0x800000b8, the next instruction here is 0x800000c0. This should not happen, the original 800000bc instruction is lost.
(gdb) ni
0x800000c4 in reset_vector ()
(gdb)
I guess this should be a bug, so report it here.
Thanks
Bob
At the moment fmin(sNaN, normal) returns normal, not qNaN.
In one test I am running, a 16bits instruction code as "8082" was printed as a MV instruction, this is wrong because this instruction is actually the C.JR instruction.
core 0: 0xffffffff8000196e (0x00008082) mv ra, zero // ---------------------This one
core 0: 0xffffffff80001a08 (0x04420613) addi a2, tp, 68
Nevertheless, although it is printed wrongly, but the PC is correct, it is indeeded executed as a C.JR instruction since next PC is jumped away.
After building spike without the device tree compiler installed, running spike yields the following message:
Failed to run : No such file or directory
It would be nice if the build failed if dtb isn't found.
When launching the simulator in debug mode with the -d
flag, the inner loop of the "interactive" mode in interactive.cc
uses 2
as a hard coded argument to the readline
function. This relates to the stderr stream, rather than the stdin
stream.
This isn't a problem when typing commands from a shell, but when controlling the simulator automatically from other scripts/flows/programs it means that one cannot automate command sequences. For example:
$> cat command-list.txt
run 100
reg 0
q
$> spike -d hello.out < command-list.txt
:
will not pipe the contents of command-list.txt into the simulator. The user is just dumped into the debug mode prompt.
Fixing the issue is a simple matter of changing the hard-coded 2
to a 0
on line 82
of interactive.cc
. I'd submit a pull request, but I don't know if this is deliberate.
Hi,
I want to get dynamic instruction count via Spike, but the disassembly codes from -d option (i.e., spike -d pk hello
and :r
) is weird.
How can I get dynamic instruction count via Spike?
I have the need to load some data into the RISCV memory space in spike before I start the simulation, but looking at the code there doesn't seem to be functionality to do this. The closest way I can see seems to be to use the addr_to_mem function in the sim_t class to get access to the memory mapped offset, but those methods are private. Is there an alternative, or should I just hack my local copy and make those public so that I can do what I need to do?
Hi
I am seeing an issue with processing the -p and -m options for spike? Note that I pulled the repo as a submodule of the riscv-tools repo.
Stephen
root@c6403e37998e:/opt/riscv# spike -m 128 +disk=linux-3.14.41/root.bin bbl linux-3.14.41/vmlinux quit
spike: argument required for option -m
usage: spike [host options] [target options]
Host Options:
-p Simulate processors [default 1]
-m Provide MiB of target memory [default 4096]
-d Interactive debug mode
-g Track histogram of PCs
-l Generate a log of execution
-h Print this help message
--isa= RISC-V ISA string [default RV64IMAFDC]
--ic=:: Instantiate a cache model with S sets,
--dc=:: W ways, and B-byte blocks (with S and
--l2=:: B both powers of 2).
--extension= Specify RoCC Extension
--extlib= Shared library to load
Hello, is there somewhere an exact information about what should be done to make possible compiling the code with added instruction? I followed all steps from "simulating a new instruction" in riscv-isa-sim readme (added a header file and a line in opcodes, and rebuilt spike) but it doesnt allow me to use new instruction. After rebuilding spike i dont have any new files in riscv-isa-sim/build and i doubt if anything is changed anywhere despite the files that i changed manually. When i try to compile code with new instruction i recieve "unrecognized opcode" error. I found somwhere on stackoverflow that the problem is that i somehow have to add instruction to assembler too, not only to simulator, but i don't know how to do it and i can't find any tips. So my question is what do i exactly have to do to write and use new instruction? Do i have to rebuild the whole toolchain or what?
Hi,
When I use the spike as the golden model to run a tests, I found the spike is not supporting the unaligned load/store instructions. But in ISA, this is the baseline feature which have to be supported. Is there any reason why Spike not support it, any plan to fix this issue?
Thanks
Bob
Hi,
I wonder if there is a mismatch between the privilege-level spec and the Spike simulator.
In the spec (Version 1.9.1 released on 11/04/16) page 22, the semantics of xRET are described as follows,
The MRET, HRET, SRET, or URET instructions are used to return from traps in M-mode, H-mode, S-mode, or U-mode respectively. When executing an xRET instruction, supposing xPP holds the value y, yIE is set to xPIE; the privilege mode is changed to y; xPIE is set to 1; and xPP is set to U.
Which means if we execute MRET in M-mode, and returns to say S-mode, MPIE should be set to 1, but in the simulator, (riscv/insns/mret.h)
s = set_field(s, MSTATUS_MPIE, 0);
Could anyone tell if this is indeed a mismatch or just my misunderstanding?
Thank you!
Hongce
Can you explain please, why am I getting differences in trace in this sim and objdump code
Test is rv32ui-p-simple,
Objdump (32bit):
00000200 <_start>:
200: f1002573 csrr a0,mhartid
204: 00051063 bnez a0,204 <_start+0x4>
208: f0002573 csrr a0,mcpuid
simulator trace (32bit pk):
core 0: 0x0000000000000200 (0x00000093) li ra, 0
core 0: 0x0000000000000204 (0x00000113) li sp, 0
core 0: 0x0000000000000208 (0x00000193) li gp, 0
core 0: 0x000000000000020c (0x00000213) li tp, 0
core 0: 0x0000000000000210 (0x00000293) li t0, 0
core 0: 0x0000000000000214 (0x00000313) li t1, 0
core 0: 0x0000000000000218 (0x00000393) li t2, 0
core 0: 0x000000000000021c (0x00000413) li s0, 0
core 0: 0x0000000000000220 (0x00000493) li s1, 0
core 0: 0x0000000000000224 (0x00000513) li a0, 0
core 0: 0x0000000000000228 (0x00000593) li a1, 0
core 0: 0x000000000000022c (0x00000613) li a2, 0
core 0: 0x0000000000000230 (0x00000693) li a3, 0
core 0: 0x0000000000000234 (0x00000713) li a4, 0
core 0: 0x0000000000000238 (0x00000793) li a5, 0
core 0: 0x000000000000023c (0x00000813) li a6, 0
core 0: 0x0000000000000240 (0x00000893) li a7, 0
core 0: 0x0000000000000244 (0x00000913) li s2, 0
core 0: 0x0000000000000248 (0x00000993) li s3, 0
core 0: 0x000000000000024c (0x00000a13) li s4, 0
core 0: 0x0000000000000250 (0x00000a93) li s5, 0
core 0: 0x0000000000000254 (0x00000b13) li s6, 0
core 0: 0x0000000000000258 (0x00000b93) li s7, 0
core 0: 0x000000000000025c (0x00000c13) li s8, 0
core 0: 0x0000000000000260 (0x00000c93) li s9, 0
core 0: 0x0000000000000264 (0x00000d13) li s10, 0
core 0: 0x0000000000000268 (0x00000d93) li s11, 0
core 0: 0x000000000000026c (0x00000e13) li t3, 0
core 0: 0x0000000000000270 (0x00000e93) li t4, 0
core 0: 0x0000000000000274 (0x00000f13) li t5, 0
core 0: 0x0000000000000278 (0x00000f93) li t6, 0
core 0: 0x000000000000027c (0xf1002573) csrr a0, mhartid
core 0: 0x0000000000000280 (0x02051063) bnez a0, pc + 32
core 0: 0x0000000000000284 (0x0000f117) auipc sp, 0xf
core 0: 0x0000000000000288 (0xd7b10113) addi sp, sp, -645
I assume that the top block of LI is just cpu restart instructions, but they start at pc=0x200, and the first test instruction is on pc=0x27c and then it jumps to 0x284 auipc sp, 0xf when objdump is said to continue with csrr a0,mcpuid. Also the bytecode is different for BNEZ instruction..
Where am I wrong?
The debug ROM writes 1s to the last word in the debug RAM to indicate an exception. However, it also uses the last word for stashing the value of S1 before running the code in the debug RAM, so the exception information is lost. The gdb support checks for exceptions in a couple of places and can misbehave when S1 is non-zero. In particular, it will send an error code for p
and P
commands, although the latter is masked by an extra OK
response (see pull request #83).
The readme shows spike --gdb-port 9824 pk tests/debug
as a way to set up debugging with gdb, but running this command doesn't work as the gdb-port option has been replaced with the rbb-port option as of d1f2cf3.
$ spike --gdb-port 9824 pk sample
spike: unrecognized option --gdb-port
usage: spike [host options] <target program> [target options]
Host Options:
-p<n> Simulate <n> processors [default 1]
-m<n> Provide <n> MiB of target memory [default 2048]
-m<a:m,b:n,...> Provide memory regions of size m and n bytes
at base addresses a and b (with 4 KiB alignment)
-d Interactive debug mode
-g Track histogram of PCs
-l Generate a log of execution
-h Print this help message
-H Start halted, allowing a debugger to connect
--isa=<name> RISC-V ISA string [default RV64IMAFDC]
--pc=<address> Override ELF entry point
--ic=<S>:<W>:<B> Instantiate a cache model with S sets,
--dc=<S>:<W>:<B> W ways, and B-byte blocks (with S and
--l2=<S>:<W>:<B> B both powers of 2).
--extension=<name> Specify RoCC Extension
--extlib=<name> Shared library to load
--rbb-port=<port> Listen on <port> for remote bitbang connection
--dump-dts Print device tree string and exit
I am unfamiliar with rbb. Is it some kind of debugging software like gdb? And why was support for gdb removed?
It looks like there's a mismatch between riscv-isa-sim and riscv-opcodes with respect to the hwacha instructions.
When I make riscv-opcodes in order to update riscv-isa-sim/opcodes_hwacha_ut.h, there's a large diff (below). I'm guessing an updated version of opcodes_hwacha_ut.h needs to be checked in.
diff --git a/hwacha/opcodes_hwacha_ut.h b/hwacha/opcodes_hwacha_ut.h
index 6a8c326..86bb28b 100644
--- a/hwacha/opcodes_hwacha_ut.h
+++ b/hwacha/opcodes_hwacha_ut.h
@@ -23,6 +23,18 @@ DECLARE_INSN(ut_amoxor_w, 0x2000202f, 0xf800707f)
DECLARE_INSN(ut_and, 0x7033, 0xfe00707f)
DECLARE_INSN(ut_andi, 0x7013, 0x707f)
DECLARE_INSN(ut_auipc, 0x17, 0x7f)
+DECLARE_INSN(ut_beq, 0x63, 0x707f)
+DECLARE_INSN(ut_bge, 0x5063, 0x707f)
+DECLARE_INSN(ut_bgeu, 0x7063, 0x707f)
+DECLARE_INSN(ut_blt, 0x4063, 0x707f)
+DECLARE_INSN(ut_bltu, 0x6063, 0x707f)
+DECLARE_INSN(ut_bne, 0x1063, 0x707f)
+DECLARE_INSN(ut_csrrc, 0x3073, 0x707f)
+DECLARE_INSN(ut_csrrci, 0x7073, 0x707f)
+DECLARE_INSN(ut_csrrs, 0x2073, 0x707f)
+DECLARE_INSN(ut_csrrsi, 0x6073, 0x707f)
+DECLARE_INSN(ut_csrrw, 0x1073, 0x707f)
+DECLARE_INSN(ut_csrrwi, 0x5073, 0x707f)
DECLARE_INSN(ut_div, 0x2004033, 0xfe00707f)
DECLARE_INSN(ut_divu, 0x2005033, 0xfe00707f)
DECLARE_INSN(ut_divuw, 0x200503b, 0xfe00707f)
@@ -66,6 +78,7 @@ DECLARE_INSN(ut_fdiv_d, 0x1a000053, 0xfe00007f)
DECLARE_INSN(ut_fdiv_h, 0x1c000053, 0xfe00007f)
DECLARE_INSN(ut_fdiv_s, 0x18000053, 0xfe00007f)
DECLARE_INSN(ut_fence, 0xf, 0x707f)
+DECLARE_INSN(ut_fence_i, 0x100f, 0x707f)
DECLARE_INSN(ut_feq_d, 0xa2002053, 0xfe00707f)
DECLARE_INSN(ut_feq_h, 0xac000053, 0xfe00707f)
DECLARE_INSN(ut_feq_s, 0xa0002053, 0xfe00707f)
@@ -125,11 +138,15 @@ DECLARE_INSN(ut_fsub_d, 0xa000053, 0xfe00007f)
DECLARE_INSN(ut_fsub_h, 0xc000053, 0xfe00007f)
DECLARE_INSN(ut_fsub_s, 0x8000053, 0xfe00007f)
DECLARE_INSN(ut_fsw, 0x2027, 0x707f)
+DECLARE_INSN(ut_jal, 0x6f, 0x7f)
+DECLARE_INSN(ut_jalr, 0x67, 0x707f)
DECLARE_INSN(ut_lb, 0x3, 0x707f)
DECLARE_INSN(ut_lbu, 0x4003, 0x707f)
DECLARE_INSN(ut_ld, 0x3003, 0x707f)
DECLARE_INSN(ut_lh, 0x1003, 0x707f)
DECLARE_INSN(ut_lhu, 0x5003, 0x707f)
+DECLARE_INSN(ut_lr_d, 0x1000302f, 0xf9f0707f)
+DECLARE_INSN(ut_lr_w, 0x1000202f, 0xf9f0707f)
DECLARE_INSN(ut_lui, 0x37, 0x7f)
DECLARE_INSN(ut_lw, 0x2003, 0x707f)
DECLARE_INSN(ut_lwu, 0x6003, 0x707f)
@@ -147,6 +164,10 @@ DECLARE_INSN(ut_remu, 0x2007033, 0xfe00707f)
DECLARE_INSN(ut_remuw, 0x200703b, 0xfe00707f)
DECLARE_INSN(ut_remw, 0x200603b, 0xfe00707f)
DECLARE_INSN(ut_sb, 0x23, 0x707f)
+DECLARE_INSN(ut_sbreak, 0x100073, 0xffffffff)
+DECLARE_INSN(ut_scall, 0x73, 0xffffffff)
+DECLARE_INSN(ut_sc_d, 0x1800302f, 0xf800707f)
+DECLARE_INSN(ut_sc_w, 0x1800202f, 0xf800707f)
DECLARE_INSN(ut_sd, 0x3023, 0x707f)
DECLARE_INSN(ut_sh, 0x1023, 0x707f)
DECLARE_INSN(ut_sll, 0x1033, 0xfe00707f)
@@ -161,6 +182,7 @@ DECLARE_INSN(ut_sra, 0x40005033, 0xfe00707f)
DECLARE_INSN(ut_srai, 0x40005013, 0xfc00707f)
DECLARE_INSN(ut_sraiw, 0x4000501b, 0xfe00707f)
DECLARE_INSN(ut_sraw, 0x4000503b, 0xfe00707f)
+DECLARE_INSN(ut_sret, 0x80000073, 0xffffffff)
DECLARE_INSN(ut_srl, 0x5033, 0xfe00707f)
DECLARE_INSN(ut_srli, 0x5013, 0xfc00707f)
DECLARE_INSN(ut_srliw, 0x501b, 0xfe00707f)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.