Re: Yet another unwinding approach

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux