> Having the vDSO do the unwinding allows the unwinding to be entirely transparent to userspace programs and libraries Why *should* unwinding be transparent to userspace programs and libraries? Userspace can contribute to making unwinding better, especially in the managed case, by hooking into the unwind mechanism and extending it. The ability to extend unwinding so that it works with interpreters and managed runtime environments implies that the userspace mechanism is accessible, not transparent. Additionally, userspace configuration can set unwind policy more flexibly than the kernel can. I'm not sure I understand the value of the "entirely transparent" argument or why it should outweigh the extensibility and efficiency advantages of putting this functionality in libc. I also haven't seen a strong rationale for putting this functionality in vDSO instead of libc. libc is the traditional place where we put all userspace bookkeeping for a Linux process. For example, libc manages the list of threads and ensures setreuid(2) atomicity across them. It would be strange and inconsistent for vDSO to take on this role at this point. How would you support interpreter and managed runtime extension of the unwind mechanism in a vDSO-based model? How would you deal with the problem of how putting a large blob of unwinder code in the vDSO would permanently pin it into memory even when unwinding is not being used? You've proposed putting the unwinder in the vDSO and thunking to it from kernel space in some manner distinct from signal delivery. I believe that while unwinding in userspace is fundamentally a good idea, both aspects of your proposed implementation depart unnecessarily from precedent and that we can achieve the same functionality with minimal changes to the current user-kernel interface by using a signal, not a new kind of kernel-directed jump to the vDSO, to start the unwind process. > languages such as Go that do not use any libc Go uses libc on operating systems like Windows, Solaris, and OpenBSD. Go's bypassing libc on Linux serves no technical purpose and should not be encouraged. That said, the mechanism I'm proposing is compatible with Go's non-libc Linux model: in this model, Go would merely have to implement the profiling signal protocol itself, without libc's help. There's nothing special or magical about libc in the model I'm proposing: the Go runtime could implement the same protocol with the kernel that libc uses. _______________________________________________ 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
