3 ms·
The clear and obvious win would have been adoption of a universal userspace generic unwind facility, like Windows has --- one that works with multiple languages
by quotemstr 3y ago
The clear and obvious win would have been adoption of a universal userspace generic unwind facility, like Windows has --- one that works with multiple languages. Turning on frame pointers is throwing in the towel on the performance tooling ecosystem coordination problem: we can't get people to fix unwind information, so we do this instead? Ugh.
- rwmj 3y agoYes, although the universal mechanisms that have been proposed so far have been quite ridiculous - for example having every program handle a "frame pointer signal" in userspace, which doesn't account for the reality that we need to do frame unwinding thousands of times a second with the least possible overhead. Frame pointers work for most things, and where they don't work (interpreted code) you're often not that interested in performance.
- quotemstr 3y ago> every program handle a "frame pointer signal" in userspace Yep. That's my proposal. > which doesn't account for the reality that we need to do frame unwinding thousands of times a second with the least possible overhead Yes, it does. The kernel has to return to userspace anyway at some point, and pushing a signal frame during that return is cheap. The cost of signal delivery is the entry into the kernel, and after a perf counter overflow, you've already paid that cost. Why would the actual unwinding be any faster in the kernel than in userspace? Also, so what if a thread enters the kernel and samples the stack multiple times before returning to userspace? While in the kernel, the userspace stack cannot change --- therefore, it's sufficient to delay userspace stack collection until the kernel returns to userspace anyway. You might ask "Don't we have to restore the signal mask after handling the profiling signal?" Not if you don't define the signal to change the signal mask. sigreturn(2) is optional.
- rwmj 3y agoThis sounds vastly more complex already than following a linked list. You've also ignored the other cost which is getting the stack trace data out of the program. Anyway I'm keen to see your implementation and test how it works in reality.
- quotemstr 3y ago[flagged]
- jart 3y agoI propose that a frame pointer daemon be introduced too, for managing the frame pointer signals. We shall modify _start() to open up an io_uring connection to SystemD so that a program may share its .eh_frame data. That way the kernel can still unwind its stack in case apt upgrade changes the elf inode.
- quotemstr 3y agoNeither of you has identified anything technically wrong with unwinding via signal and neither of you has proposed a mechanism through which we might support semantically informative unwinding through paged-out code or interpreted languages. Sarcasm is not a technical argument.
- jart 3y agoI don't need to. Fedora and Ubuntu have already changed their policies to restore frame pointers. As far as I can tell, your proposal is no longer on the table. If you aren't willing to accept the decision, then you should at least understand that the onus is on you now to justify why things need to change.
- quotemstr 3y ago> It's such a clear and obvious win that the rest of us should have the opportunity to persuade them > I don't have to Pick one, jart.
- jart 3y agoCosmopolitan Libc does frame pointer unwinding once per function call, when the --ftrace flag is passed. https://justine.lol/ftrace/ https://justine.lol/ftrace/