mimicking gomp_thead(void) for OMPD-API implementation

mimicking gomp_thead(void) for OMPD-API implementation

[Ahmed Sayed Mousse]

Hi everyone,

               To implement the function ompd_get_thread_handle (…) from
the OMPD API. I need to get  the gomp_thread struct using thread context
and address space context and in order to do that I want to apply the
functionality of/mimic  gomp_thread(void) from lipgomp.h using callbacks
but I don't know which of those two approaches should I use or whether I
should use both.


#elif defined HAVE_TLS || defined USE_EMUTLS
extern __thread struct gomp_thread gomp_tls_data;
static inline struct gomp_thread *gomp_thread (void)
{
  return &gomp_tls_data;
}
#else
extern pthread_key_t gomp_tls_key;
static inline struct gomp_thread *gomp_thread (void)
{
  return pthread_getspecific (gomp_tls_key);
}
#endif


My current thought is to try looking for the gomp_tls_data symbol and if I
don't find it I go looking for the gomp_tls_key then use
pthread_getspecific() on it.


Here is the current approach I think about using:


    lookup('gomp_tls_data')

    if return code != ok)

        go to try_key

    .....


    go to allocation

    try_key:

    lookup('gomp_tls_key')


    .....


    allocation:


    .....


    end of function


If I should use both should I save the first lookup by saving the result of
the first condition, if defined HAVE_TLS || defined USE_EMUTLS,  from
runtime in the shared library and then check on that result?


like

#if defined HAVE_TLS || defined USE_EMUTLS

#define GOMPD_USE_TLS

#endif

Thanks.

Re: mimicking gomp_thead(void) for OMPD-API implementation

[Jakub Jelinek]

On Thu, Jun 02, 2022 at 11:13:11AM +0200, Ahmed Sayed Mousse via Gcc wrote:
>                To implement the function ompd_get_thread_handle (…) from
> the OMPD API. I need to get  the gomp_thread struct using thread context
> and address space context and in order to do that I want to apply the
> functionality of/mimic  gomp_thread(void) from lipgomp.h using callbacks
> but I don't know which of those two approaches should I use or whether I
> should use both.
> 
> 
> #elif defined HAVE_TLS || defined USE_EMUTLS
> extern __thread struct gomp_thread gomp_tls_data;
> static inline struct gomp_thread *gomp_thread (void)
> {
>   return &gomp_tls_data;
> }
> #else
> extern pthread_key_t gomp_tls_key;
> static inline struct gomp_thread *gomp_thread (void)
> {
>   return pthread_getspecific (gomp_tls_key);
> }
> #endif

I'd suggest looking at https://github.com/llvm/llvm-project/blob/main/openmp/libompd/src/omp-debug.cpp
etc.  Please don't copy any code from it, but just to get the idea
how things can work.

libgomp actually supports not just the above 2 ways how to get at
struct gomp_thread, but 4, one is for NVPTX offloading target, one for GCN
offloading target, then one for working native thread local storage and
one for pthreads where native thread local storage doesn't work well.

I think it is too early to bother with offloading support for OMPD, so feel
free to ignore those 2 for now, and I'd also suggest if pthread_getspecific
is used for gomp_thread that you also just punt (return an error from
ompd_get_thread_handle), at least for now, because I really have no idea
how in the APIs you could run in the inferior some library function.

As for gomp_tls_data, that is a TLS variable and so it is very similar to
the LLVM libompd case where __kmp_gtid is also a __thread variable.
So, you need to call the get_thread_context_for_thread_id callback
to get the ompd_thread_context_t *, then lookup the gomp_tls_data symbol
using symbol_addr_lookup with that ompd_thread_context_t *.
Now, in the libomp case, __kmp_gtid is just some number one then uses as
index into __kmp_threads which is a pointer to pointer, this is indexed
by the __kmp_gtid number and inside of what it points to it picks the th
union member and returns address of that union member + the address space
handle + thread context.
Now, the libgomp #elif defined HAVE_TLS || defined USE_EMUTLS case is
simpler, the address of the TLS var is what one cares about, so some
steps from what LLVM libompd does can be avoided.

	Jakub