对于stack_backtrace的疑问在于,打印参数我是使用取栈上第3个数,因为前面一次函数调用的参数会存在x19,当当前函数对x19使用时,我的理解是编译器会产生指令对x19压栈以保存上下文,那么在backtrace的函数中如果我选择直接打印栈上第三个数的话,得到会是一个错误的结果,因为此时当前函数并没有对x19造成修改。因此x19并没有压栈,也就是说固定打印栈上第三个数作为前函数的第一个参数这种做法其实是存在错误的,对吗?
我在做的时候跟你也有同样的疑问,把fp往上取第三个u64开始作为函数参数。跑qemu-gdb的时候我也感觉这参数不太对,但make grade运行backtrace的时候,这么做参数又是没问题的。。我只能猜测栈上参数的位置取决于最后编译命令,可能在make grade的时编译参数disable了一些gcc的优化,使得参数不管有没有被修改都在栈上第三个位置,大部分时候都不是这样的
Rorshach 确实我感觉这是取决于编译器,我尝试过直接在stack_backtrace打印栈的第三个参数,就是除了这个打印之外没有其他任何代码,这个情况下结果是错误的,通过gdb可以看到这个时候不需要任何寄存器的修改,所以x19没有被push到栈上。
zenotme Rorshach 是的,以上问题依赖编译器,但是我们通过加编译选项,使得正常编译执行的情况下模式是固定的,但是使用gdb会发生一些变化。也可以通过使用一下x19,将backtrace固定下来
ds_ssj 明白了!谢谢!😁