On Mon, Jan 16, 2023 at 11:33 PM Daniel Colascione <dan...@dancol.org> wrote: > > > 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.
Linux is the only operating system where it supports libc-less compilation nowadays. It is the exception, rather than the rule. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
