Notes on first-party unwinding
Hi all, Per our discussion at the end of the call today, I wanted to get a few things written down while I’m still thinking about them, based on my past experience with stack walking: * Writing the helper macro for appropriate inline assembly to get a frame pointer is trivial per-platform but you do need to force the frame pointer to exist. GNU even provides intrinsics to get RA/FP portably: https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html <https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html>. Though that’s not something I’ve worked with personally and I don’t know how portable “portable” is there. * As Joachim pointed out, name lookup/matching is what makes things at all expensive. It’s generally worth a fair bit of precomputation and hashing so that we can make fast decisions based on the return address alone. * If we can make the simplifying assumption that a single tool may not use the PMPI and QMPI interfaces, we can probably use library-sized address ranges to decide how to classify a return address—which tool owns it and thereby how it should appear/not appear on the stack. (Well, subject to the further assumption that a tool library contains MPI wrapper functions and things called by those wrapper functions. Is that something we feel we can require of tools?) Cheers, Bill -- Bill Williams Wiss. Mitarbeiter ZIH-IAK, TU-Dresden Falkenbrunnen, Room 009 Chemnitzer Straße 50 01187 Dresden Phone: +49 351 463-39976 e-mail: [email protected]
participants (1)
-
William Williams