[mpiwg-tools] Notes on first-party unwinding

Wesley Bland work at wesbland.com
Fri Oct 30 13:49:40 CDT 2020


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 <mpiwg-tools at lists.mpi-forum.org> 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:   william.williams at mailbox.tu-dresden.de <mailto:william.williams at mailbox.tu-dresden.de>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20201030/2ab2ce0b/attachment.html>


More information about the mpiwg-tools mailing list