[mpiwg-tools] Notes on first-party unwinding

[William Williams]

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:   william.williams at mailbox.tu-dresden.de






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20201029/e65aa88b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5120 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20201029/e65aa88b/attachment-0001.p7s>