On Wed, 25 Sept 2024 at 11:29, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Wed, Sep 25, 2024 at 10:43:50AM +0100, Jonathan Wakely wrote:
> > > libgcc/ChangeLog:
> > >
> > > * gthr-posix.h (__GTHREAD_INLINE): New macro.
> > > (__gthread_active): Convert from variable to function.
> > > (__gthread_trigger): Mark as __GTHREAD_INLINE instead of static.
> > > (__gthread_active_p): Likewise.
> > > (__gthread_create): Likewise.
> > > (__gthread_join): Likewise.
> > > (__gthread_detach): Likewise.
> > > (__gthread_equal): Likewise.
> > > (__gthread_self): Likewise.
> > > (__gthread_yield): Likewise.
> > > (__gthread_once): Likewise.
> > > (__gthread_key_create): Likewise.
> > > (__gthread_key_delete): Likewise.
> > > (__gthread_getspecific): Likewise.
> > > (__gthread_setspecific): Likewise.
> > > (__gthread_mutex_init_function): Likewise.
> > > (__gthread_mutex_destroy): Likewise.
> > > (__gthread_mutex_lock): Likewise.
> > > (__gthread_mutex_trylock): Likewise.
> > > (__gthread_mutex_timedlock): Likewise.
> > > (__gthread_mutex_unlock): Likewise.
> > > (__gthread_recursive_mutex_init_function): Likewise.
> > > (__gthread_recursive_mutex_lock): Likewise.
> > > (__gthread_recursive_mutex_trylock): Likewise.
> > > (__gthread_recursive_mutex_timedlock): Likewise.
> > > (__gthread_recursive_mutex_unlock): Likewise.
> > > (__gthread_recursive_mutex_destroy): Likewise.
> > > (__gthread_cond_init_function): Likewise.
> > > (__gthread_cond_broadcast): Likewise.
> > > (__gthread_cond_signal): Likewise.
> > > (__gthread_cond_wait): Likewise.
> > > (__gthread_cond_timedwait): Likewise.
> > > (__gthread_cond_wait_recursive): Likewise.
> > > (__gthread_cond_destroy): Likewise.
> > > (__gthread_rwlock_rdlock): Likewise.
> > > (__gthread_rwlock_tryrdlock): Likewise.
> > > (__gthread_rwlock_wrlock): Likewise.
> > > (__gthread_rwlock_trywrlock): Likewise.
> > > (__gthread_rwlock_unlock): Likewise.
> > > * gthr-single.h (__GTHREAD_INLINE): New macro.
> > > (__gthread_active_p): Mark as __GTHREAD_INLINE instead of static.
> > > (__gthread_once): Likewise.
> > > (__gthread_key_create): Likewise.
> > > (__gthread_key_delete): Likewise.
> > > (__gthread_getspecific): Likewise.
> > > (__gthread_setspecific): Likewise.
> > > (__gthread_mutex_destroy): Likewise.
> > > (__gthread_mutex_lock): Likewise.
> > > (__gthread_mutex_trylock): Likewise.
> > > (__gthread_mutex_unlock): Likewise.
> > > (__gthread_recursive_mutex_lock): Likewise.
> > > (__gthread_recursive_mutex_trylock): Likewise.
> > > (__gthread_recursive_mutex_unlock): Likewise.
> > > (__gthread_recursive_mutex_destroy): Likewise.
>
> I'm worried about ABI consequences of these changes.
> From what I can see, this doesn't change anything important for C,
> the inlines are still static inline and the conversion of global static
> vars to function-local in static inline still keeps those static.
>
> But for C++ this means significant changes.
> Say
> _ZZ16__gthread_activevE20__gthread_active_var
> etc. will now be STB_GNU_UNIQUE symbol, exported from whatever shared
> libraries and binaries are compiled with C++ and include those headers
> and actually use them somewhere.
I don't think that applies for HPUX or Solaris, but maybe does for
FreeBSD (and it looks like those are the only targets affected by the
__gthread_active_var changes).
> On one side, it has benefits (e.g. every TU won't separately test and
> store whether the threads are active or not), on the other side it can
> prevent dlclose of some shared libraries and create interdependencies
> between libraries.
>
> So, I wonder if we couldn't define the C++ __GTHREAD_INLINE to
> static inline __attribute__((__always_inline__)) (or at least when
> using a compiler which supports the attribute, we can now test it
> using preprocessor...).
I think that would be a nice improvement for the gthread wrapper
functions even without the concern about __gthread_active_var.
> And whether similarly we couldn't use
> __attribute__((__visibility__ ("hidden"))) on the static block scope
> vars for C++ (again, if compiler supports that), so that the changes
> don't affect ABI of C++ libraries.
That sounds good too.
