shinezyy
commented
2 months ago 您的 bug 报告简直 awesome！我会尽快尝试复现这个 bug
我会尝试把你的 bug report 做成 issue 模板，非常感谢！
- 对于 nemu 生成的 checkpoint，xs-gem5并不一定能够正确恢复，这是一个正常现象吗？还是这本身就是一个不应该出现的情况。 在版本正确时，99%的情况下不应该出现
- 对于 xs-gem5 的开发，在开发过程中难免要进行调试。请问香山团队采取的调试方法是 difftest 结合 dprintf 产生 log 的方法进行调试的吗？ difftest + dprintf + gdb
- 对于上面这样的问题，根据日志能够确定发生错误的时机在 4172118372 ticks 之后，香山团队在调试类似问题的时候会采用 gdb 进行调试，然后在 4172118372 ticks 停下然后进行调试的方法吗，我还没有验证过这样的方法是否可行。
这是我用 gdb 调试的时候修改脚本的方法：
我一般只看看 backtrace，或者 watch 一个 host address。gem5 在 gdb 的符号解析不一定好用
zybzzz
在使用 XS-GEM5 恢复 NEMU 产生的检查点时产生段错误。
环境描述：
交叉编译工具链：riscv-gnu-toolchain的预编译版本 其版本为 13.2.0 其他环境同b站checkpoint生成示范视频
问题发现过程： 我想使用xs-gem5进行自己的体系结构探索。我按照b站的视频编译了 SPEC2006 的 benchmark，编译选项全部为仓库默认，在编译完 benchmark 之后我使用 qemu-riscv跑了我想用的 benchmark，并没有报错。随后我按照视频过程将 benchmark打包到了riscv-pk 中，并使用 nemu 仓库中给定的默认脚本进行 checkpoint 的生成。随后成功生成了多个 checkpoint，我使用 nemu 恢复 checkpoint，均正常退出。随后希望将这些 checkpoint 从 gem5 中恢复从而进行体系结构探索。
我首先将 gem5 切换到上文给定的分支，并随机选取了一个benchmark，按照 README 中的要求执行默认脚本，gem5正确退出并生成统计数据结果（由此，我以为整个环境就搭建完成了，实际上应该是一种错觉）。随后我自己对xs-gem5中的代码进行了相关的改动，我期望将 checkpoint 运行于我改动过后的 xs-gem5 之上，来查看自己改动xs-gem5相关结构的结果，在解决完多个我自己程序的问题之后，我发现xs-gem5 仍然会在运行 checkpoint 的时候报出段错误，我在运行命令的脚本中增加了 debug-flag的选项：
并运行命令：
在 debug.log 的最后几行显示：
对于日志的分析显示好像是在对gem5中内存进行访问的时候报出了段错误。起先我认为是自己的改动问题，但是我自己的代码本身没有对LSQ进行修改。于是我尝试将xs-gem5切换回未改动的分支运行相同的checkpoint：
运行这个 checkpoint 的时候未改动的 xs-gem5 没有报错。我尝试使用别的 checkpoint：
未改动的xs-gem5仍然产生同样的段错误，日志内容也相似。 产生的日志内容最后显示：
虽然访问的地址不同，但是貌似是同样的原因产生了段错误，上述的两个过程中 difftest 均没有报错。随后我开始对 checkpoint 进行相关的检测，我挑选了几个 checkpoint ，同样放在未修改过的 xs-gem5 上跑，发现对于 nemu 能够正确恢复的 checkpoint，在 xs-gem5 上并不能够正确恢复。我使用的 checkpoint 在这个链接中能够进行下载，我将未修改的xs-gem5中能正常退出的 checkpoint 放在 right 目录下，在未修改的xs-gem5中产生段错误的检查点放在 error 目录下。至于对于我自己修改过的 xs-gem5 ，上面所有的检查点都会产生段错误。
我想请问这种情况可能是什么原因导致的？应当如何解决。以上的代码都是我上个星期从仓库获取的，考虑到香山更新速度快，我会尝试切换到更新的提交按照 README 再进行尝试。
另外我想问的是：
刚刚接触 xiangshan 系列的项目，理解欠佳，如果有理解错误的地方烦请见谅。谢谢！
其他关键信息：
benchmark编译选项为SPEC2006LiteWrapper仓库的默认选项：
在编译的时候并没有开启向量化的支持，因此编译出的程序只是包含 riscv64GC 的，因此我按照 README，设置
$GCB_REF_SO和$GCB_RESTORER，全程都是开启 difftest 的，上面产生报错的过程 difftest 均没有出现问题。作为运行的 benchmark，我挑选了 bbl 中的 gcc benchmark 打包进 bbl,initramfs.txt 中的 benchmark 部分为：
nod /dev/console 644 0 0 c 5 1 nod /dev/null 644 0 0 c 1 3
libraries
file /lib/ld-linux-riscv64-lp64d.so.1 ${RISCV}/sysroot/lib/ld-linux-riscv64-lp64d.so.1 755 0 0 file /lib/libc.so.6 ${RISCV}/sysroot/lib/libc.so.6 755 0 0 file /lib/libresolv.so.2 ${RISCV}/sysroot/lib/libresolv.so.2 755 0 0 file /lib/libm.so.6 ${RISCV}/sysroot/lib/libm.so.6 755 0 0 file /lib/libdl.so.2 ${RISCV}/sysroot/lib/libdl.so.2 755 0 0 file /lib/libpthread.so.0 ${RISCV}/sysroot/lib/libpthread.so.0 755 0 0
busybox
file /bin/busybox ${RISCV_ROOTFS_HOME}/rootfsimg/build/busybox 755 0 0 file /etc/inittab ${RISCV_ROOTFS_HOME}/rootfsimg/inittab-spec 755 0 0 slink /init /bin/busybox 755 0 0
SPEC common
dir /spec_common 755 0 0 file /spec_common/before_workload ${RISCV_ROOTFS_HOME}/rootfsimg/build/before_workload 755 0 0 file /spec_common/trap ${RISCV_ROOTFS_HOME}/rootfsimg/build/trap 755 0 0
SPEC
dir /spec 755 0 0 file /spec/run.sh ${RISCV_ROOTFS_HOME}/rootfsimg/run.sh 755 0 0 file /spec/gcc_base.gcc ${SPEC_BUILD_PATH}/gcc_base.gcc 755 0 0 file /spec/scilab.i ${CPU2006_RUN_DIR}/gcc/scilab.i 755 0 0
riscv-pk 下的 noop.dtsi 并无改动，最关键的是 memory 部分没有进行改动仍然保持为：
对于 nemu 下的 gcpt.lds 并没有改动，通过反汇编能够发现，gcpt.bin 这边 bbl 恢复的地址确实是 0x800a0000。