From nobody Fri Feb 02 20:07:35 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TRRds4J5xz589ZR for ; Fri, 2 Feb 2024 20:07:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TRRdr0Rbbz4vCF; Fri, 2 Feb 2024 20:07:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=troutmask.apl.washington.edu header.s=troutmask header.b=BXiYyIyw; dmarc=fail reason="No valid SPF" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 412K7Z9h016907; Fri, 2 Feb 2024 12:07:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 412K7Z9h016907 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706904455; bh=dWrNm5GMnUonNJirJBrjRCf1FRX/BBVMSQgwSA2HmEA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=BXiYyIywOKg8w+kfBZbgzUQ8+Zbm5Snepv9aQ9TRL21j0PG5yGL+yadV6brUnvxRv CywRuCVVngyJNeqMU6BS5cT48/e95+j+l3LqDxcI/hrQTKtSVfjHKvxLOL0Z1yxh5X WFUHVckR0JFiJCjnLooC2sZhWCjVYXR5d4rhxhvT35+GpjOEwNX75/MXt82Aquz8/u 3hy+4edbvSOAJzDQTVVfkMM9L4zEPmhQIlGMAA2kOW6vdG9viX1haRMzgsARGge4K/ LdMP4RklIB+qfzant14s08PMkjzXK3BR2z06Ez6/I8m9YFzSV8NvjmoSpVEW7y5MqT C3W6k4+R4qN7A== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 412K7Zs5016906; Fri, 2 Feb 2024 12:07:35 -0800 (PST) (envelope-from sgk) Date: Fri, 2 Feb 2024 12:07:35 -0800 From: Steve Kargl To: Konstantin Belousov Cc: Mike Karels , Dimitry Andric , FreeBSD CURRENT Subject: Re: llvm ld vs binutils ld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.63 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; NEURAL_HAM_SHORT(-0.90)[-0.901]; NEURAL_HAM_LONG(-0.77)[-0.765]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF,none]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_PERMFAIL(0.00)[troutmask.apl.washington.edu:s=troutmask]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_NA(0.00)[no SPF record]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[troutmask.apl.washington.edu:~]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4TRRdr0Rbbz4vCF On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote: > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote: > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote: > > > On 27 Jan 2024, at 18:08, Steve Kargl wrote: > > > > > > > > In an attempt to cleanup a bit of src/lib/msun, I ran into > > > > a small issue that I cannot explain at the moment. If I have > > > > /usr/bin/ld in my path prior to /usr/local/bin/ld everything > > > > works > > > > > > > > % which ld > > > > /usr/bin/ld > > > > % make clean && make cleandepend > > > > % make > > > > > > > > and I have a libm.so.5. But if /usr/local/bin/ld is found, I > > > > see > > > > > > > > % cd msun > > > > % make clean && make cleandepend > > > > % make > > > > .. > > > > ld: error: version script assignment of 'FBSD_1.0' to symbol 'fabs' \ > > > > failed: symbol not defined > > > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > > > *** Error code 1 > > > > > > > > Stop. > > > > make: stopped in /usr/src/lib/msun > > > > > > > > % grep fabs /usr/src/lib/msun/Symbol.map > > > > fabs; > > > > fabsf; > > > > fabsl; > > > > > > > > But, if one looks in msun/Makefile, one see > > > > > > > > # FreeBSD's C library supplies these functions: > > > > #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c > > > > > > > > so fabs is not built with libm. > > > > > > > > % nm --dynamic /lib/libc.so.7 | grep fabs > > > > 00000000000ba600 T fabs > > > > % nm --dynamic /lib/libm.so.5 | grep fabs > > > > 000000000001fa90 T fabsf > > > > 00000000000252e0 T fabsl > > > > > > > > > > > > Is this a known issue? Should fabs be removed from Symbol.map? > > > > > > Yes, fabs is excluded in msun's Makefile: > > > > > > # FreeBSD's C library supplies these functions: > > > #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c > > > > Thanks for the quick response. I knew this, but > > > > > so it should not have been in Symbol.map at all. > > > > it has been this way for a very long time. > > > > > The comment is also > > > incorrect, since s_frexp.c and s_isnan.c *are* actually in COMMON_SRCS, > > > see lines 79 and 80 of the Makefile. (They are indeed also in libc, so > > > which one is chosen is only known by the linker. :) > > > > I would it depends on the search order of the libraries. For > > static linking, it's the order on the commandline. For rtld, > > it's the order of the libraries in the cache. > > > > % nm --dynamic /lib/libc.so.7 | grep snan > > 00000000000ace30 T __isnan@@FBSD_1.0 > > 00000000000ace60 T __isnanf@@FBSD_1.0 > > 00000000000ace30 W isnan@@FBSD_1.0 > > 00000000000ace60 W isnanf@@FBSD_1.0 > > % nm --dynamic /lib/libm.so.5 | grep snan > > 00000000000220a0 T __isnanf@@FBSD_1.2 > > 00000000000220d0 T __isnanl@@FBSD_1.0 > > 00000000000220a0 W isnanf@@FBSD_1.0 > > > > Not quite. isnan is in libc but libm. isnanf seems to be > > in both, and isnanl is only in libm. Does FBSD_1.2 trump > > FBSD_1.0 for __isnanf? > No, the binary specifies which version of the symbol it wants, either > __isnanf@FBSD_1.2 or __isnanf@FBSD_1.0, and the dynamic linker binds to > the version. > > Which version is recorded into the consumer binary, is up to the static > linker (ld), and there it is normally defined by the order of the libraries > specified on the command line. Thanks for the explanation, but I think I now have a conundrum. Suppose I have two shared libraries libfoo.so and libbar.so, and suppose bah@@XXX_1.0 is in libbar.so's symbol map. If my main program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar', then the linker finds bah@XXX_1.0. Now suppose a developer adds a new procedure to libfoo.so and she just so happens to name her new function bah() with a symbol map entry of bah@YYY_a.b. Which bah@ is linked when rebuilding or loading 'z'? Does it depend on the search order for ld-config.so.1? -- Steve