On Sat, Apr 09, 2022 at 12:38:11AM +0200, Ahmed Sayed Mousse wrote:
> Sorry for the late reply.
> I did check gomp_thread_self but I'm still not sure about what I should do,
> maybe because I lack experience/knowledge.
> Here is where my thinking is going right now and I hope you tell me if I'm
> wrong.
Sorry for the delay, I've been busy with GCC 12.
> in gomp_thread_to_pthread_t there are 4 possible outputs
> 1 - if LIBGOMP_USE_PTHREADS is enabled
> {
> first pthread_self() if the thread calling is the same thread as the
> function input.
> or gomp_thread->handle in case GOMP_NEEDS_THREAD_HANDLE is enabled.
> or pthread_self () + ((uintptr_t) input_thread - (uintptr_t)
> calling_thread)
> }
ompd_get_thread_id is for mapping of the OMPD thread id to the native
thread id. If LIBGOMP_USE_PTHREADS, we are using POSIX threads, so
OMPD_THREAD_ID_PTHREAD is what we want to provide.
If GOMP_NEEDS_THREAD_HANDLE, then we want to read the handle member for
it and return it. Otherwise as the comment says, we optimize and
because we know that in the initial-exec TLS model &gomp_tls_data -
pthread_self ()
is the same for each thread, we don't store the handle at all, so
ompd_get_thread_id instead needs to compute the bias.
If it is too hard to do it in libgompd.so alone, perhaps during
gompd_load libgomp.so.1 could compute it and store in some variable
that libgompd.so can then read.
> 2 -if LIBGOMP_USE_PTHREADS not enabled
> - empty struct casted to a pthread_t
> currently think i should check for the GOMP_NEED_THREAD_HANDLE, if it's
> enabled i extract the pthread_t from the gomp_thread handle given in the
> function and return that.
> If it's not enabled then I return an empty struct or an rc_unspported
> return code.
> Note:
> The openmp specification doesn't really tell me how things should be
> done so I get confused a lot and I think I have a misunderstanding of the
> function.
> I would appreciate it a lot if I get any directions to where I can
> increase my knowledge around this part.
If LIBGOMP_USE_PTHREADS is not enabled, then it is libgomp.a built for one
of the offloading targets, either NVPTX or GCN. We then can't return
OMPD_THREAD_ID_PTHREAD, threads are numbered differently there, they are
either the CUDA threads or GCN threads. But I think at least initially
we only build libgompd.so for the host so how exactly we OMPD offloading
should be postponed until after the host handling works.
Jakub
