NetBSD Problem Report #58847

From www@netbsd.org  Fri Nov 22 16:42:39 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E1D4A1A9238
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 22 Nov 2024 16:42:38 +0000 (UTC)
Message-Id: <20241122164237.9B8D01A923E@mollari.NetBSD.org>
Date: Fri, 22 Nov 2024 16:42:37 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: libzpool exports atomic_*_64* on some architectures
X-Send-Pr-Version: www-1.0

>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
>Last-Modified:  Fri Nov 22 23:50:01 +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!

>Audit-Trail:
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/58847 CVS commit: src/external/cddl/osnet/lib/libzpool
Date: Fri, 22 Nov 2024 16:50:15 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Fri Nov 22 16:50:15 UTC 2024

 Removed Files:
 	src/external/cddl/osnet/lib/libzpool: zpool.expsym

 Log Message:
 libzpool: Nix expsym for now.

 On some architectures this spuriously exports atomic_*_64 symbols,
 and that should really be fixed first so we don't have to go to the
 trouble of machine-dependent expected symbol lists.

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

 PR PR lib/58838: shared libraries in base should all have expsym lists


 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r0 src/external/cddl/osnet/lib/libzpool/zpool.expsym

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Brad Spencer <brad@anduin.eldar.org>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: lib/58847: libzpool exports atomic_*_64* on some architectures
Date: Fri, 22 Nov 2024 18:46:04 -0500

 campbell+netbsd@mumble.net writes:

 >>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:


 [snip]

 There is this snip in src/share/mk/bsd.own.mk that indicates that ZFS is
 only on 64 bit systems.

 #
 # We want to build zfs only for amd64, aarch64 and sparc64 by default for now.
 #
 .if ${MACHINE} == "amd64" || \
     ${MACHINE} == "sparc64" || \
     ${MACHINE_ARCH:Maarch64*}
 MKZFS?=         yes
 .endif


 At one time, the ZFS libraries (at the very least) were built on 32 bit
 systems, but that stopped happening some time ago.  This PR may have
 just stumbled upon a dead branch.  I know that when I tried to build ZFS
 on i386 a short time ago in -current it blew up and wouldn't compile a
 release.

Home	PR Database Search