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

Reply via email to