Notes 2015 08 24

Attendees

• John DelSignore
• Marc-Andre Hermanns
• Michael Knobloch
• Kathryn Mohror
• Soren Rasmussen
• Jeff Squyres
• Anh Vo

Notes

• MPIR - Anh presented changes to MQD document for indicating when an MPI process is being debugged
  • Everyone likes the changes Anh made since last time
  • Only one typo-like change to make before it's ready
  • How do we make this change official?
    • To be blessed by the forum, it's a reading and 2 votes
    • Plan for reading in Bordeaux
• MPIR - Anh presented DLL loading changes to MPIR document
  • Some framework changes to the document, thinking towards the future when we add new features, e.g. Handle Introspection
  • Left out motivation example from Sun for the DLL array
    • But we'll want to put in some kind of rationale or explanation for why it's needed even without the example
  • Some discussion on whether or not the vector of DLL names will need to be updated at any point during the run
    • Much discussion of how to handle this, with issues of atomicity/race conditions coming up
    • However no real use cases....
    • Seems to be a complex solution to a problem that doesn't exist
    • For now, the vector is immutable once it is set
      • Put some rationale about why we decided to make it immutable, so we don't forget this chain of thought
      • We can relax it later if an actual issue comes up
  • Do we need a query function that indicates whether this DLL thinks it can run with this process in this environment?
    • Dlopen doesn't work, just because you can dlopen a library doesn't mean it is compatible
    • mqs_version string, mqs_version_compatibility: this is just compatibility with the MQS version
      • Need a deeper check than these offer
    • What about setup_image?
    • We went through the list of steps in the MPIR document about how a debugger gets set up
      • In doing this, realized that these are in fact all the steps that need to be done to see if a DLL is compatible
      • So, a debugger will go through the normal steps up through step 5
        • If everything passes, it's good
        • If anything fails, stop and try a different DLL
      • We need a new error code that indicates the DLL is not compatible
  • Since we're going through the regular steps, maybe we don't need a new chapter for this functionality anymore
    • Just incorporate it in the existing text, make it section 3.4.1
• What is the increment number for the MPIR document?
  • We should publish a 1.1 of all our side documents: MPIR 1.1, MQD 1.1
  • But wait, the MPIR changes are introducing new behavior. Does 1.1 make sense?
    • How does MPI know which behavior the debugger will follow? 1.0 or 1.1
    • Do we have a way to tell?
    • Do we need a way to modify the target memory to indicate the version/capabilities?
    • Or should the implementation just provide a variable that the debugger can write to?
  • Jeff will read the current being_debugged (MQD) text in Bordeax