lib/58847: libzpool exports atomic_*_64* on some architectures

[campbell+netbsd%mumble.net@localhost]

>Number:         58847
>Category:       lib
>Synopsis:       libzpool exports atomic_*_64* on some architectures
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 22 16:45:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The Atomic_NetBSZ Foundation
>Environment:
>Description:
As a horrible workaround for missing __HAVE_ATOMIC64_OPS on 32-bit platforms that support zfs (mainly i386 and arm32), libzpool has a local and very much non-atomic definition of symbols like atomic_cas_64.

It's bad enough that we have the non-atomic definition -- maybe it's not a problem today, or a low-probability problem, for userland use of libzpool but we really shouldn't have this kind of crap lying around -- but libzpool.so actually exports the symbols so anything linking against it gets them.

Working around this is troublesome because sys/atomic.h has the equivalent of:

__BEGIN_DECLS (i.e., _Pragma("GCC visibility push(default)"))
uint64_t atomic_cas_64(volatile uint64_t *, uint64_t, uint64_t);
...
__END_DECLS (i.e., _Pragma("GCC visibility pop"))

We can annotate the definitions in libzpool/atomic.c with __dso_hidden = __attribute__((__visibility__("hidden"))) but gcc refuses to respect the definition's visibility when it doesn't match the declaration's.
>How-To-Repeat:
build zpool with machine-independent zpool.expsym on i386
>Fix:
Yes, please!