On Wed, 25 Sept 2024 at 11:47, Jonathan Wakely <jwak...@redhat.com> wrote:
>
> 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.
Can you use visibility attributes on a local static? I get a warning
that it's ignored.
