> Could the vDSO do the unwinding? The vDSO is just userspace code that happens to be provided by the kernel, so, sure, a function in vDSO *could* unwind. But why would it? What would be the advantage of doing that over putting the unwinding in libc? To change the vDSO, you have to change the kernel, so the vDSO is more suited for things coupled to the kernel, like a fast clock_gettime implementation. Also, libc can be paged out, and the vDSO can't be. It's hard to imagine a DWARF unwinder entirely in vDSO and resident in memory all the time being the optimal system design choice. Code in libc is paged into memory on demand. Putting the unwinder in libc seems more natural, especially since libc is a natural coordination point for "plugging in" runtime-specific unwinders, which is one of the advantages of a usermode-unwinding scheme. I don't think there's a lot of precedent for the vDSO providing registration and plugin mechanisms. Besides: since libc already reserves a signal for itself (SIGRTMIN), using the same signal for kernel-requested unwinding (distinguished by si_code, one would imagine) wouldn't break any new code. _______________________________________________ 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
