输出重定向时保存堆栈指针会导致分段错误
我正在编写一个 Sparc 编译器。我的一个测试用例正常运行良好，但当输出重定向到文件时崩溃。
使用GDB，我发现这是导致段错误的行：
save %sp, -800, %sp
我的堆栈空间不足吗？这是怎么回事？为什么只有当我重定向输出时才会发生这种情况？
I'm writing a Sparc compiler. One of my test cases runs fine normally, but crashes when the output is redirected to a file.
Using GDB, I have found that this is the line that causes the segfault:
save %sp, -800, %sp
Am I out of stack space? What's the deal? How come it only happens when I redirect the output?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SPARC 中的
save指令只能通过窗口溢出陷阱触发段错误。如果出现以下情况，就会发生这种情况：后者意味着事件的发生存在不可预测性。这是因为溢出的发生取决于先前的寄存器窗口使用情况 - 溢出的确切发生可能会通过分时共享同一 CPU 的其他进程所做的事情而改变。 Solaris 不会在每次上下文切换时自动溢出设置的整个注册表窗口，因为这会损害性能。例如，两个使用 8 个窗口（堆栈帧）的工作负载可能会愉快地互相抢占，并在具有 >= 16 个寄存器窗口的 CPU 上完全“无堆栈”运行。
我可以想象，由于输出重定向，溢出的可能性可能会增加（写入文件侧的堆栈比写入控制台侧更深的堆栈更有可能驱逐进程的注册表胜利）。
如果是这种情况，那么如果您将后台 CPU / 堆栈占用者（在循环中递归阶乘 200000，以永久废弃注册表窗口）绑定到测试用例正在处理的相同CPU。
A
saveinstruction in SPARC can trigger a segfault only through window spill traps. That would happen if:The latter means there's an element of unpredictability in the occurance. That is because the occurance of spills depends on previous register window usage - the exact occurance of the spill can change through what other processes that timeshare the same CPU have been doing. Solaris will not auto-spill the entire reg window set on every context switch because that'd hurt performance. E.g. two workloads that use eight windows (stackframes) each might happily preempt each other and run fully "stack-free" on a CPU with >= 16 reg windows.
I can imagine that spill likelyhood might increase in due to output redirecting (deeper stacks on the write-to-file than write-to-console side are more likely to evict your process' reg wins).
If this is the case then you should be able to force consistent failure of your testcase even without the output redirect if you bind a background CPU / stack hogger (recursive factorial of 200000, in a loop, to permanently trash the reg windows) onto the same CPU where your testcase is processing.