Describe the bug
When instrumenting a test with dump_stack() to debug a stack corruption problem it appears that only zeros are output for memory locations which have non-zero data.
To Reproduce
Observed this on the latest rev hash 05c8987 running on MacOS.
The behavior is observed in the test case already available in test/syscalls/mem_dump_syscalls.exe
Expected behavior
stack dump should match values observed in trace has having been written
Trace
The trace shows memory location 0x9fffeb is writing with data here.
RevCPU[cpu:Render:2000]: Core 0; Hart 0; Thread 1; *I 0x1120a:e022 c.sdsp s0, 0(sp) 0x9fffeb<-sp 0x12d48<-s0 [0x9fffeb,8]<-0x0000000000012d48
There are no further writes to this address.
The stack_dump() produces this
RevCPU[cpu:ECALL_dump_stack:35500]: ECALL: dump_stack called
0x00000000009fffeb: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000000009ffffb: 00 00 00 00
Describe the bug
When instrumenting a test with dump_stack() to debug a stack corruption problem it appears that only zeros are output for memory locations which have non-zero data.
To Reproduce
Observed this on the latest rev hash 05c8987 running on MacOS.
The behavior is observed in the test case already available in test/syscalls/mem_dump_syscalls.exe
Expected behavior
stack dump should match values observed in trace has having been written
Trace
The trace shows memory location 0x9fffeb is writing with data here.
RevCPU[cpu:Render:2000]: Core 0; Hart 0; Thread 1; *I 0x1120a:e022 c.sdsp s0, 0(sp) 0x9fffeb<-sp 0x12d48<-s0 [0x9fffeb,8]<-0x0000000000012d48
There are no further writes to this address.
The stack_dump() produces this
RevCPU[cpu:ECALL_dump_stack:35500]: ECALL: dump_stack called
0x00000000009fffeb: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000000009ffffb: 00 00 00 00