On 11/7/22 09:59, Daniel Alley wrote: > The references of the proposal has some discussion on this subject. > Basically, this was already considered and rejected by the kernel > developers including Torvalds directly on the basis that DWARF > unwinding support is simply too complex and nonperformant to be > allowed in the kernel. Three other options I can think of: 1. Use an out-of-tree kernel module, as systemtap does. 2. Find a better unwind information format for userspace. 3. Do the actual unwinding in userspace in the context of the process being profiled. The last option can be implemented by having the unwind code be in the vDSO. This requires that the kernel inject an asynchronous interrupt to userspace, but that is no different than calling a signal handler. This also solves other problems: bugs in the unwinder do not compromise or crash the kernel, and the unwinding code can take page faults if necessary. Even with -fno-omit-frame-pointer, frame pointer unwinding will still be unreliable. There is a significant amount of assembler code in e.g. glibc that does not maintain a frame pointer, and I suspect the same is true for OpenSSL and other libraries. I am also not sure if OCaml supports generating frame pointers, and I know that GHC does not. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
