Mark Wielaard <mjw@xxxxxxxxxxxxxxxxx> writes: > 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. Yep. SIGSEGV in the unwinder could just longjmp back to the top of the unwinder. BTW: I'm imagining overloading SIGRTMIN+0, not SIGPROF, because SIGRTMIN+0 is already reserved for libc. _______________________________________________ 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
