Hi Florian, On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote: > * Daniel Colascione: > > > See, both pro-FP and anti-FP camps think that it's the kernel that has > > to do the unwinding unless we copy whole stacks into traces. > > Well, I think we should explore hardware-assisted backtraces (shadow > stacks), which hopefully are going to get merged in Linux 6.2. Yes, that is also a good alternative if available. The shadow stack seems to be ideal because it is just the function return addresses, which basically is just the backtrace you are looking for. > If the unwind information is incomplete, this … > > > 7) signal handler unwinds the calling thread however it wants (and can > > sleep and take page faults if needed) > > … might encounter segmentation faults and terminate the process. So > far, incorrect unwind information (whether it's a clobbered frame > pointer, or missing DWARF information about clobbered registers) is not > a problem, but it's kind of hard to validate this information from > within the process itself. Maybe we'd have to add a magic memcpy first > to the vDSO, which the kernel recognizes based on the code addresses, > and suppresses sending the signal for it. Yeah, I am not too afraid of that happening with an .eh_frame based unwinder unless someone deliberately produced a bad table (or dlcloses a library which still has code on the call stack). You still have to be careful about the stack bounds of course. But it is something to keep in mind, accidents happen. I assume that any (seg) fault caused by the unwind signal thread will simply end that contribution of user space to the backtrace (instead of really generating a SEGV) But it is tricky to handle that without kernel support. As a fallback you could install a SIGSEGV handler that handles the fault and somehow makes the original SIGPROF based handler (if you use that) sigreturn. Cheers, Mark _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
