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 <mohamedatef1...@gmail.com>
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 <mjam...@suse.cz> 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
>>
>
