Re: GNU OMPD implementation
Hello, sorry for replying this late, I'm looking into different things and my context switches are slow. On Wed, Nov 24 2021, Mohamed Atef wrote: > Hello everyone, > I need to remind you that we are working on implementation of OMPD, so > you don't make it open for GSoC this year. I can assure you we will not accept an OMPD-implementation GSoC project, because I consider it just too big for effort of one individual. > > our progress so far, > We are working on a GDB extension using python so we can provide OMPD with > callbacks. > Jakub said that we need GDB support, but the GDB community didn't reply to > us although we mailed them more than one time, so is it okay to build the > plugin and extend GDB with python for testing purposes ? I *think* that since the "third party" should use OMPD library in a OpenMP-implementation-agnostic way, for this particular bit you should be able to look at how clang OMPD guys have "hacked" gdb to interface with the OMPD library ...and maybe re-use that without much extra effort? > > to enable OMPD the runtime must provide some routines like: > ompd_dll_locations_valid(void) > void ompd_bp_parallel_begin(void) > void ompd_bp_parallel_end(void) > void ompd_bp_task_begin(void) > void ompd_bp_task_end(void) > and define the variable const char **ompd_dll_locations. > so far so good , BUT OMPD can not access debug information at the runtime, > so it needs to access them What do you mean by "them?" these particular symbols, including the functions? Or internal run-time data structures in general? > We will write some macros for that. > the macros will generate the sizes and offsets for the following structs: > gomp_team > gomp_task_icv > > Should we generate all structs sizes? Jakub will eventually need to comment on this but please gie an example of what macroization you have in mind. If it is too ugly, we can discuss alternatives. Thanks, Martin
Re: New ThreadSanitizer runtime (v3)
On 11/22/21 20:01, Dmitry Vyukov wrote: I've already reverted the change. So I will include a fix into the next version. Thanks for notifying. Hello. Am I correct that the patch set is installed again? Any near future plans for another revert of the patch? Do you think it's the right time to merge it to GCC? Thanks, Martin
Work on the power-ieee128 branch has hit a snag...
... in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476, a very strange error where an invalid Makefile is generated with --enable-maintainer-mode on POWER. I'm not sure how to proceed from here. Maybe somebody with more make debug fu could take a look? Best regards Thomas
Re: Work on the power-ieee128 branch has hit a snag...
* Thomas Koenig via Gcc: > ... in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476, a very > strange error where an invalid Makefile is generated with > --enable-maintainer-mode on POWER. > > I'm not sure how to proceed from here. Maybe somebody > with more make debug fu could take a look? What's the whitespace situation? Usually the error means that the recipe is indented using spaces instead of tab. It's spaces in Bugzilla, but that doesn't mean much. Thanks, Florian
Re: Work on the power-ieee128 branch has hit a snag...
On 29.11.21 20:42, Florian Weimer via Fortran wrote: What's the whitespace situation? Usually the error means that the recipe is indented using spaces instead of tab. The error is on the line $(i_matmulavx128_c): m4/matmulavx128.m4 m4/matmul_internal.m4 $(I_M4_DEPS) where there is no whitespace. I have checked the Makefile, there is a tab on the next line, as it should be. That is what has me baffled...
Re: Work on the power-ieee128 branch has hit a snag...
... which has been resolved. There was a stray semicolon in quite another place which led to this error. Thanks to Andreas for finding this so quickly! Best regards Thomas
Re: GNU OMPD implementation
Hello, for the gdb part it's already understood. gdb documentation explains how to extend gdb functionality using python, and we looked at clang code and now it's very clear how to provide OMPD functions with parameters. >From OpenMP API specification 5.1 section 5.6 "The OpenMP implementation must define several entry point symbols through which execution must pass when particular events occur and data collection for OMPD is enabled. A tool can enable notification of an event by setting a breakpoint at the address of the entry point symbol." We need to add OMPD support to libgomp, and the debugger should be notified that it has entered a new parallel region so we make dummy functions (or labels) at every start and end of (parallel, task, thread) regions (note : they should not be optimized). for the structures that we need to access in the runtime for example here: https://github.com/gcc-mirror/gcc/blob/master/libgomp/icv.c#L38 if OMPD needs to get the max threads of the target program it literally repeat the call so we use callbacks to get the address of struct gomp_task_icv then we read its value the we get the value of nthreads_var variable for example : callbacks->lookup(icv)->access(nthreads_var) for now: We finished the initialization phase and we're now working on how to test the initialization of both the library and the target process. We finished 5.5.1, 5.5.2, but for 5.5.4 i need to know the OpenMP version. Where is the variable of the OpenMP version defined? --- Current issues, to get the variable names from the target needs to move from the debugger space to the target process space to lookup the values so we can use something like (std::map) to save the values of the symbols that we got before but we don't use C++. Can we use C++ ? . If not, Can we implement it ourselves? Now we're thinking of leaving it as it's (access the target every time you need to read or lookup.) and after finishing the project we can think of something like caching the variables or any other way. OMPD will support CPUs for now. Is that okay? for the macroziation part: the lookup and read_memory callbacks should be provided with the sizes of the variable they need to look for or read? OMPD doesn't know the size of runtime data structures and can not access the dwarf at the runtime. so we need to do that manually: #define OMPD_FOREACH_SIZEOF(OMPD_SIZEOF)\ OMPD_SIZEOF(gomp_task_icv)\ OMPD_SIZEOF(gomp_task)\ OMPD_SIZEOF(gomp_team) #define OMPD_DECLARE_SIZEOF(t) __UINT64_TYPE__ ompd_sizeof__##t; OMPD_FOREACH_SIZEOF(OMPD_DECLARE_SIZEOF) #undef OMPD_DECLARE_SIZEOF we will generate these symbols as needed, so it's okay. Thanks, Mohamed On Mon, Nov 29, 2021 at 3:55 PM Martin Jambor wrote: > Hello, > > sorry for replying this late, I'm looking into different things and my > context switches are slow. > > On Wed, Nov 24 2021, Mohamed Atef wrote: > > Hello everyone, > > I need to remind you that we are working on implementation of OMPD, > so > > you don't make it open for GSoC this year. > > I can assure you we will not accept an OMPD-implementation GSoC project, > because I consider it just too big for effort of one individual. > > > > > our progress so far, > > We are working on a GDB extension using python so we can provide OMPD > with > > callbacks. > > Jakub said that we need GDB support, but the GDB community didn't reply > to > > us although we mailed them more than one time, so is it okay to build the > > plugin and extend GDB with python for testing purposes ? > > I *think* that since the "third party" should use OMPD library in a > OpenMP-implementation-agnostic way, for this particular bit you should > be able to look at how clang OMPD guys have "hacked" gdb to interface > with the OMPD library ...and maybe re-use that without much extra > effort? > > > > > to enable OMPD the runtime must provide some routines like: > > ompd_dll_locations_valid(void) > > void ompd_bp_parallel_begin(void) > > void ompd_bp_parallel_end(void) > > void ompd_bp_task_begin(void) > > void ompd_bp_task_end(void) > > and define the variable const char **ompd_dll_locations. > > so far so good , BUT OMPD can not access debug information at the > runtime, > > so it needs to access them > > What do you mean by "them?" these particular symbols, including the > functions? Or internal run-time data structures in general? > > > We will write some macros for that. > > the macros will generate the sizes and offsets for the following structs: > > gomp_team > > gomp_task_icv > > > > Should we generate all structs sizes? > > Jakub will eventually need to comment on this but please gie an example > of what macroization you have in mind. If it is too ugly, we can > discuss alternatives. > > Thanks, > > Martin >
Re: New ThreadSanitizer runtime (v3)
On Mon, 29 Nov 2021 at 19:16, Martin Liška wrote: > > On 11/22/21 20:01, Dmitry Vyukov wrote: > > I've already reverted the change. So I will include a fix into the next > > version. > > Thanks for notifying. > > Hello. > > Am I correct that the patch set is installed again? Any near future plans for > another > revert of the patch? Do you think it's the right time to merge it to GCC? It has been re-landed at least twice since then :) Well, I can't promise that it won't be reverted again. I obviously do not want that. Hard to say. I need to send some follow up clean up patches and I plan to wait till the end of the week (to avoid messy multi commit reverts). So if there are no deadlines to miss, I would suggest waiting until the beginning of the next week.
Re: GNU OMPD implementation
Hi, I forgot to give full details about macros. after the declaration we got type called ompd_sizeof_(gomp_task) for example then we can use sizeof operator to get its size: #define OMPD_INIT_SIZEOF(t) ompd_sizeof_##t = sizeof(t); OMPD_FOREACH_SIZEOF(OMPD_INIT_SIZEOF) #undef OMPD_INIT_SIZEOF Thanks Mohamed On Tue, Nov 30, 2021 at 2:23 AM Mohamed Atef wrote: > Hello, > for the gdb part it's already understood. gdb documentation explains > how to extend gdb functionality using python, and we looked at clang code > and now it's very clear how to provide OMPD functions with parameters. > > From OpenMP API specification 5.1 section 5.6 > "The OpenMP implementation must define several entry point symbols through > which execution > must pass when particular events occur and data collection for OMPD is > enabled. A tool can enable > notification of an event by setting a breakpoint at the address of the > entry point symbol." > > We need to add OMPD support to libgomp, and the debugger should be > notified that it has entered a new parallel region so we make dummy > functions (or labels) at every start and end of (parallel, task, thread) > regions (note : they should not be optimized). > > for the structures that we need to access in the runtime > for example here: > > https://github.com/gcc-mirror/gcc/blob/master/libgomp/icv.c#L38 > > if OMPD needs to get the max threads of the target program it literally > repeat the call so we use callbacks to get the address of struct > gomp_task_icv then we read its value the we get the value of nthreads_var > variable > for example : callbacks->lookup(icv)->access(nthreads_var) > > for now: > We finished the initialization phase and we're now working on how to test > the initialization of both the library and the target process. > We finished 5.5.1, 5.5.2, but for 5.5.4 i need to know the OpenMP version. > Where is the variable of the OpenMP version defined? > > --- > > Current issues, > > to get the variable names from the target needs to move from the debugger > space to the target process space to lookup the values so we can use > something like (std::map) to save the values of the symbols that we got > before but we don't use C++. > Can we use C++ ? . If not, Can we implement it ourselves? > Now we're thinking of leaving it as it's (access the target every time you > need to read or lookup.) and after finishing the project we can think of > something like caching the variables or any other way. > > OMPD will support CPUs for now. Is that okay? > > > > for the macroziation part: > the lookup and read_memory callbacks should be provided with the sizes of > the variable they need to look for or read? > OMPD doesn't know the size of runtime data structures and can not access > the dwarf at the runtime. > so we need to do that manually: > #define OMPD_FOREACH_SIZEOF(OMPD_SIZEOF)\ > OMPD_SIZEOF(gomp_task_icv)\ > OMPD_SIZEOF(gomp_task)\ > OMPD_SIZEOF(gomp_team) > > #define OMPD_DECLARE_SIZEOF(t) __UINT64_TYPE__ ompd_sizeof__##t; > OMPD_FOREACH_SIZEOF(OMPD_DECLARE_SIZEOF) > #undef OMPD_DECLARE_SIZEOF > > we will generate these symbols as needed, so it's okay. > > Thanks, > > Mohamed > > > > On Mon, Nov 29, 2021 at 3:55 PM Martin Jambor wrote: > >> Hello, >> >> sorry for replying this late, I'm looking into different things and my >> context switches are slow. >> >> On Wed, Nov 24 2021, Mohamed Atef wrote: >> > Hello everyone, >> > I need to remind you that we are working on implementation of OMPD, >> so >> > you don't make it open for GSoC this year. >> >> I can assure you we will not accept an OMPD-implementation GSoC project, >> because I consider it just too big for effort of one individual. >> >> > >> > our progress so far, >> > We are working on a GDB extension using python so we can provide OMPD >> with >> > callbacks. >> > Jakub said that we need GDB support, but the GDB community didn't reply >> to >> > us although we mailed them more than one time, so is it okay to build >> the >> > plugin and extend GDB with python for testing purposes ? >> >> I *think* that since the "third party" should use OMPD library in a >> OpenMP-implementation-agnostic way, for this particular bit you should >> be able to look at how clang OMPD guys have "hacked" gdb to interface >> with the OMPD library ...and maybe re-use that without much extra >> effort? >> >> > >> > to enable OMPD the runtime must provide some routines like: >> > ompd_dll_locations_valid(void) >> > void ompd_bp_parallel_begin(void) >> > void ompd_bp_parallel_end(void) >> > void ompd_bp_task_begin(void) >> > void ompd_bp_task_end(void) >> > and define the variable const char **ompd_dll_locations. >> > so far so good , BUT OMPD can not access debug information at the >> runtime, >> > so it needs to access them >> >> What do you mean by "them?" these particular symbols, including the >> functions? Or internal run-time data structures in general? >> >> > We will write some mac
