Thanks Bill. We’ll take a look at this for our implementation. It does seem like this is going to be the best strategy, though these sorts of implementation details probably won’t make much difference for the specification side of things. Thanks, Wes
On Oct 29, 2020, at 11:40 AM, William Williams via mpiwg-tools <[email protected]> wrote:
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] <mailto:[email protected]>
_______________________________________________ mpiwg-tools mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools