3 ms·
vDSO is a good way to mitigate issues like these. It's also a better stable ABI than libc, and easier to maintain than pure kernel ABI (like Linux does), becaus
by prepperdev 6y ago
vDSO is a good way to mitigate issues like these. It's also a better stable ABI than libc, and easier to maintain than pure kernel ABI (like Linux does), because nobody forbids the kernel to inject different vDSOs to different binaries, if a need arises.
vDSO is also a language independent construct, so there's no special treatment for any favorite language, be it C (OpenBSD), C++ (Windows) or Oberon OS (Oberon).
vDSO: https://en.wikipedia.org/wiki/VDSO https://en.wikipedia.org/wiki/VDSO
- remexre 6y agovDSO functions are still allowed to use arbitrary amounts of stack though, which means Go might still have problems with them without having to allocate much larger stacks than it normally would.
- masklinn 6y agoIn fact that is an issue Go hit in the past: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
- prepperdev 6y agoThat would be up to a specific OS to decide which guarantees on stack size limit would it like to provide. But I agree that it's a valid concern, and not all possible vDSO implementations are reasonable.