[Openmp-dev] Fwd: Implementation of OMPD
Wilmarth, Terry L via Openmp-dev
openmp-dev at lists.llvm.org
Mon Mar 19 12:22:50 PDT 2018
Pinging on this, didn’t see any replies. A couple responses from me inline below, but it would be great if we could get more feedback on this soon.
Thanks!
Terry
-----Original Message-----
From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On Behalf Of Joachim Protze via Openmp-dev
Sent: Tuesday, February 6, 2018 4:42 AM
To: Openmp-dev <openmp-dev at lists.llvm.org>
Cc: Laguna Peralta, Ignacio <lagunaperalt1 at llnl.gov>; Protze, Joachim <protze at itc.rwth-aachen.de>
Subject: [Openmp-dev] Fwd: Implementation of OMPD
Hi all,
we briefly discussed the following with Jonathan, Andrey and Hansang at the OpenMP LC F2F meeting last week.
OpenMP 5.0 will not only bring OMPT, which is already implemented in trunk, but also OMPD. OMPD is an interface for tools that execute in a separate process (aka. third-party tools), which is typically the case for debuggers. The architecture of OMPD is similar to libthread_db.# A preliminary specification of OMPD can be found in TR6 of the spec.
We were working internally on an implementation while specifying the interface. We are currently pushing the code to the repository of the OpenMP tools working group:
https://github.com/OpenMPToolsInterface/LLVM-openmp
Similar as with OMPT, we will develop and update the implementation in this repository and then push the implementation to trunk.
To get started, we want to clear some organizing questions:
Name of the OMPD library?
We have several names in discussion: libompd.so, libomp-debug.so,
libompdebug.so, or libomp_db.so
[I like libompd.so or libomp_db.so, but am a bit indifferent on this.]
From the interface point of view the name does not matter, the runtime
will contain a breadcrumb telling the debugger the name of the library.
Directory tree?
Finally, OMPD will give a tool insight into host runtime and at the same
time into the device runtime. Therefore we suggest to create a new
directory at the top level, i.e., new sibling to runtime and libomptarget.
The suggested name for the directory is the library name.
[Agreed.]
Tests?
[Yes ☺ I don’t think tests are a blocking issue on getting this into trunk though. See below.]
The architecture of OMPD requires a tool loading the debugging library.
The tool needs to provide basic debugging functionality (lookup names,
reading memory, ...) to the library. While it is possible to implement
basic regression tests as a standalone application, to test the real
functionality, an OpenMP application executing under control of a
debugging tool is necessary. To verify the consistency of information
provided by OMPD, we can compare the information to OMPT or OpenMP
runtime calls.
During our development, we worked with Dyninst for automatic regression
testing. The same workflow could also be implemented with another
debugger like gdb (, or probably lldb?)
[Would the infrastructure you used for testing work inside of LIT?
If you can provide your infrastructure, then maybe others can use it to add tests for whatever debuggers they like.
We could have gdb or lldb be tested by default.]
The question here, what is the preferred approach for testing? What
dependencies are acceptable?
Thanks,
Joachim
PS: Sorry for double-post in case my earlier mail gets through moderation.
--
Dipl.-Inf. Joachim Protze
IT Center
Group: High Performance Computing
Division: Computational Science and Engineering
RWTH Aachen University
Seffenter Weg 23
D 52074 Aachen (Germany)
Tel: +49 241 80- 24765
Fax: +49 241 80-624765
protze at itc.rwth-aachen.de<mailto:protze at itc.rwth-aachen.de>
www.itc.rwth-aachen.de<http://www.itc.rwth-aachen.de>
_______________________________________________
Openmp-dev mailing list
Openmp-dev at lists.llvm.org<mailto:Openmp-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20180319/1cf95873/attachment.html>
More information about the Openmp-dev
mailing list