Debugging 单步模式

是否存在与x86的单步模式等效的SPARC？我想要的是在每个指令之后停止执行，并将控制流移动到陷阱处理程序或类似的东西

---

我曾想过在延迟执行槽中使用

ta

指令，但如果前一条指令是带有环形位集的分支指令，这将不起作用。

Sparc在PSR中缺少单步位，因此单步执行比较困难。但我用了一个小把戏来拉近距离。将TPC设置为要单步执行的指令的地址，并将TNPC设置为放置陷阱指令的其他位置的地址。当您执行retry指令返回到进程上下文时，它将单步执行您想要的一条指令，然后它将执行trap指令，这将直接返回内核，在那里您可以做任何您想要的事情。（注意：这是针对sparc64的，不确定sparc32的）。这是一个很好的技巧，因为您不必修改用户地址空间中的现有指令。这对我很重要，因为我是内核中的单步指令

---

我还有一个想法，但从未尝试过，就是简单地将TNPC设置为非法地址。然后，在TPC上的指令执行之后，您会自动将陷阱返回到内核中。而且，由于陷阱处理代码知道进程是单步执行的，因此不会对“真实”非法地址陷阱产生混淆。

我认为您应该替换Tcc指令，并通过解码指令和查看保存的NPC寄存器值来处理延迟槽。。。。除非第一条指令是跳转到非法地址（在有缺陷的程序中）。也许您可以选择您的非法地址，这样就不会发生这种情况，至少不需要相对跳转，但可能寄存器间接跳转可以将您带到任何地方。（我不知道SPARC的详细信息，不知道这是否是一个真正的问题，或者陷阱处理程序是否有足够的信息来解决这个问题。）我可以想出几种方法来解决这个问题。首先，您可以读取要单步执行的指令，查看它是否是寄存器间接跳转，并对其进行解码以找到源寄存器和任何偏移量，然后计算跳转的目标并将其保存，以便在非法地址陷阱后与TPC值进行比较。第二，把我们放在TNPC中的非法地址当作元数据；用伪随机数填充，然后确认出错的非法地址相同。如果不是，那么非法地址是由分步指令引起的，而不是由我们的地址引起的。这两种方法听起来都很麻烦。如果您碰巧没有生成目标代码将跳转到的相同地址，那么依靠这种机会可能是安全的（特别是对于64位地址），但最好做一些保证安全的事情。将TNPC指向陷阱指令可以避免所有这些吗？这似乎是显而易见的方法。是的，当然安全的做法是将TNPC指向陷阱指令。所有其他的谈话都只是为了好玩，我从来没有试过。想一个简单的方法来检测用户生成的非法地址和我们生成的地址之间的区别：在非法地址之后的陷阱处理程序中，查看TNPC。如果它与陷阱之前的情况相同，那么这意味着阶梯式指令出现故障。很好，也许可以将其编辑到您的答案中。顺便说一句，我基本上只知道x86，但有些人知道其他ISA是如何设计的。ISA支持在其他机器上调试，特别是使用分支延迟插槽，这很有趣。