Hi, On Sun, May 31 2020, y2s1982 . wrote: > Hello team, > > I just wanted to give an update to my current progress. I spent most of the > time looking over OMPD documentation again and studying LLVM's approach to > it. >
thanks a lot, sorry about replying this late again, unfortunately I missed your email on Monday and only noticed it yesterday. [...] >> >> 1) We are used to reviewing patches in our email clients and prefer it >> to reviews in web-based tools. I have quite a lot of customizations >> in place that I am used to and so prefer it to >> one-method-fits-everyone web tools. >> > I understand. This kind of information is exactly what I wanted to know so > I can adjust my work process to fit the community needs. My I follow the > above process of making PR but also create a patch using 'git diff' command > and share that with the mailing list? yeah, sure, although I think people usually use git format-patch. > >> >> 2) Do not spend too much time thinking about how to organize the >> project. The time is better spent actually thinking about the >> project itself, particularly because I expect this one to entail a >> lot of experimenting with an occasional dead end. >> > I understand. I just thought this discussion belonged to me getting to know > how to work with the community and therefore fit the community bonding > period theme. I am very excited to get to actually work, too. > >> >> >> Having said that, if you'd like to do a hangouts video call to say hello >> >> to each other and perhaps to discuss some issues with setting up your >> >> work, I personally am definitely happy to do that too. As a regular >> >> communication tool, I did not find videoconferencing to be very useful >> >> in the past (but I guess I can be persuaded to try again). >> > >> > Hmm. In my last coop that ended during pandemic, we used the video >> > conferencing tool to do daily stand-ups so the team can keep tabs on how >> > different parts of the project is going and give suggestions as needed. A >> > little off-topic, but how often would you like to discuss my progress of >> > the project? >> >> So... ideally the stream of emails discussing the overall approach, >> followed by a stream of patches and reviews would make it completely >> unnecessary to ask you for some kind of regular status reports. >> Nevertheless, if some task takes you more than a 4-5 work-days in which >> you don't get back to us, please send us a quick summary of what you >> have been working on. This arrangement of course means that you need to >> reach out to us if you believe you are stuck, so please do. >> >> But let me reiterate that I am willing to try a videoconference or two >> if you think it would be useful at any point. >> > Would it be nice to have a face-to-face conversation perhaps in the first > week of June? Perhaps open to any interested community member to discuss > the beginnings of the OMPD? OK, so me not noticing the email made that impossible, I'm afraid. But let's try the 2nd week. Feel free to offer a suitable time. I plan to ping Jakub on IRC tomorrow and see if/when he'd be willing to attend. >> >> No, GCC, the compiler, reads C and then goes through various stages of >> intermediate representations of the C code, one of which is gimple, >> optimizes it and produces an assembly. >> >> If that C file contains OpenMP directives (and you compile with >> -fopenmp) many of those are converted in one way or another into calls >> into the "GNU offloading and multi-processing (run-time) library:" >> libgomp. It used to be just GNU OpenMP library but now it is also the >> run-time library for OpenACC. >> >> For example, #pragma omp parallel is compiled in a way that the body of >> the construct is outlined into a special artificial function and the >> construct itself is compiled into a call to a function GOMP_parallel, >> with a reference to the function with the body passed in one of the >> parameters. In gimple optimized dump, the function is called >> __builtin_GOMP_parallel which I admit is slightly confusing, but it is >> the same thing - and the concept should be well visible in the dump. >> >> GOMP_parallel is a function in libgomp. Grep-ing for it in the libgomp >> subdirectory finds it in parallel.c. From the dump you should have good >> idea what it receives in its parameters. Reading a large chunk of >> libgomp source code starting there - and perhaps at other such entry >> points - is probably a good idea. >> > > I think I will study the libgomp library first week of June. I will keep > the above in mind as I look over the code. Now that I have more > understanding of OMPD, I aim to find relevant functions that I could use > for OMPD. > > >> > I skimmed through the documentation to familiarize with the interface. I >> > would have to read more on it as I go through the development. >> > I also looked at the clang project. I could see how some of the document >> > was used to create headers and constants. What I didn't get is their >> > references to gdb: does that mean something different in clang or is that >> > referencing GCC's gdb? An entire folder is dedicated to gdb-wrapper, for >> > example, and a commit history also references gdb. >> >> I can only guess they indeed refer to GNU gdb. >> > > In an effort to understand how I might go about starting the OMPD project, > I spent some time studying LLVM's attempt. Following are my findings and > some questions. > > The LLVM's repository for OMPD development is at this github repo > <https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests>, > under the branch ompd-test. > The OMPD documentation > <https://www.openmp.org/spec-html/5.0/openmpse43.html#x242-16540005.1> states > that the omp-tools.h be available. I believe it is https://github.com/OpenMP/sources/blob/master/include/omp-tools.h It should be referenced somewhere from the openmp.org but possibly actually isn't. > The closest thing to this I found > was in this > .var file > <https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/runtime/src/include/50/omp-tools.h.var>, > though I am not familiar enough to understand how this translate to > omp-tools.h file later. After this, things got a little more interesting. > First, they seem to be using GNU gdb as the debugger. From there, their older > attempt > <https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-wrapper>, > stored > in a folder called "gdb-wrapper", seems to work around with creating a > C/C++ wrapper. This seems to be in the process of being replaced with > gdb-plugin idea, as represented in this git issue > <https://github.com/OpenMPToolsInterface/LLVM-openmp/issues/77> and their > current CMakeList.txt > <https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/libompd/CMakeLists.txt>. > The gdb-plugin > <https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-plugin> > seems > to rely on python to implement OMPD. So by now you may know quite a bit more about LLVM's OMPD effort than I do but it rather seems like they use the python gdb scripts to call into a python module written in C - which in term uses OMPD interface to get information about the debugged program - in order to provide the user with useful OpenMP context. I only looked at them quickly but they do not look anything like an implementation. > For example, other than the fact that > most of the code in the folder is written in python, the ompdModule.c's > _read() > <https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/gdb-plugin/ompdModule.c#L504-L534>, > which corresponds to ompd_callback_memory_read_fn_t typedef > <https://www.openmp.org/spec-html/5.0/openmpsu209.html#x264-17550005.4.3.2> > defined > in the OMPD documentation, creates and manipulates PyObject throughout the > function implementation. Right. But looking at the python scripts I really tend to think they are simply OMPD users. > > I am left with a couple of questions: > First of all, they seem to be working with gdb to provide OMPD solution in > forms of wrapper/plugin. Can we use this code, too? What kind of issues do > we have with licensing? We do take the sanitizer run-time library code from LLVM upstream, so I think it is possible, in principle. but... > > Secondly, the LLVM team started from C/C++ wrapper and moved on to Python > implementation. ...again, maybe I'm misunderstanding you, but the implementation is not in python. For example, the first function in the OMPD spec, ompd_initialize, is implemented in libompd/src/omp-debug.cpp. Also, the LLVM effort should probably only serve as a reference. The main design question is how to implement the interfaces from the OMPD spec in libgomp (or how to make an OMPD component/tool get the required info from libgomp). Martin
