On Thu, Apr 04, 2019 at 02:24:09PM +0200, Martin Jambor wrote: > > I know my first email is vague. I wanted to throw it out there since > > the April 9th deadline is coming up. > > I was hoping Jakub Jelinek, who would be the mentor, would chime in > earlier. But unfortunately he has probably not been online in the past > few days. (And I admit I struggle a little bit to answer all GSoC email > in a timely manner this week too).
Sorry, I've been on vacation last week. > >>Also what would the goals and timeline look like? > > For this, especially the timeline, we probably need Jakub's input. The > goal would be to implement a substantial portion of the spec, but I > cannot quickly provide any guidance about how time consuming different > parts are likely to be. It doesn't have to be a full OMPD spec implementation in the end, a major portion thereof might be enough, it needs to be usable, on the other side doesn't necessarily mean also writing GDB support to use that; it would be nice to be in touch with some GDB folks (CCed Kevin) and discuss the implementation with them too. Likely no changes on the compiler side should be needed, as few changes in libgomp.so.1 as possible (the goal is not to slow down the runtime if possible, if not possible at least minimize the slow down and if possible make it conditional on the process being actually OMPD debugged) and most of it would be writing a new shared library with the OMPD APIs that a debugger or similar tool can dlopen and use. Ideally the OMPD shared library would use https://infinitynotes.org/wiki/Infinity to communicate structure offsets and how to get various properties from the libgomp.so.1 shared library, but if it turns out to be too hard for a start, doing it some other way initially might be acceptable too. The implementation should also add <omp-tools.h> and <ompd-types.h> headers, similar to the sample ones in https://github.com/OpenMP/sources/tree/master/include and actually implement the APIs in there. Jakub
