From nobody Mon Dec 20 20:53:43 2021 X-Original-To: toolchain@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 A38771900DD7; Mon, 20 Dec 2021 20:53:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHsJL6y8tz3D8j; Mon, 20 Dec 2021 20:53:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 883D9D1D4; Mon, 20 Dec 2021 20:53:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F1DEB54E2A; Mon, 20 Dec 2021 21:53:52 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: /stable/12 future From: Dimitry Andric In-Reply-To: <5CA8FE25-F46A-4902-9FFC-266347C88021@FreeBSD.org> Date: Mon, 20 Dec 2021 21:53:43 +0100 Cc: toolchain@freebsd.org, freebsd-arm@freebsd.org Message-Id: References: <5CA8FE25-F46A-4902-9FFC-266347C88021@FreeBSD.org> To: Jan Beich X-Mailer: Apple Mail (2.3693.40.0.1.81) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640033635; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ptq0RhsJHvZVlj9sSCVsvzuJwGPDw8PiHuMA6ZssNS8=; b=iDRSaGz6AKBACQBoMsasrA/jhjmf1t7vHxDLvX0qPrnwpBviOW5P3R56qyQTk/YGeOQsvr +aPZduObCp5axnmID92Wuti4Dq7mwbIXt+QhlRrsuhPRnXYASLXlRBtDrsmsfZ/v2GjJNv A4Grn8E26Xmfj5n1olDwlwUEvaNHVynxEzrh+N4AIScU87A5TKX2sCMEMa7ZPQdfu7sxTx /FbnnPygP0VyeAP6clP2SWiQfXlsuykev1dBz8E0c/rw1LY9wCS4WzC9X71gDSIC0mkqnQ rbhK03DiDU5feTSTvg1sNoQsiu23fWHXGfm98Fe5OIRYu95o4v16NC+dX7yYiA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640033635; a=rsa-sha256; cv=none; b=Yex39JikFHVV3ByPXcHsxatpO+/aHWmF3zilHrq7iIjFZxT1SUHNfvX1Egy52doy2GWLKl 7ncAT8keXFGKdL/KnCjtzn5c0Ct4p0pqCJl6c3zvNqM59PO6mTH5249oUsP7wscakrljw7 7Wnq6nMRwO9vyc33XCBrl1HHKNcCIDKjuWzq4QhhvioTchJn2KTsn4pa2tfmogoZIzISHv h+HVcy4vLOJxifCO5rVpFFhb7XmVNMAxn4kAzUEtOVyj/x5dG8c6IJmept72NCc+yzbrEx 77Kd+HtGd8pZemSLWYeMrYwp28Ut6ciMrQ44OhpODBxDHfsevNgnqLtSjLY3iQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 8 Dec 2021, at 21:58, Dimitry Andric wrote: > > On 8 Dec 2021, at 20:47, Jan Beich wrote: >> >> 12.3-RELEASE still uses Clang/libc++ 10 from 1 year ago. Do you plan >> to update in future as /stable/12 is supported until 2024-06-30? >> >> libc++ lags behind libstdc++ on C++20 features and sticking to an old >> version puts the entire branch on a deathbed. Given drm-kmod on >> /stable/12 is stuck with Linux 4.16 era (discontinued after 2018-06-26) >> /stable/12 is already mostly dead from desktop POV. >> >> See also >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215193 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260139` > > I'd rather merge llvm-project 13.0.0 to stable/12, but I didn't want to > do this just before 12.3 wrapped, and it's also a bit of a hassle to > figure out all the cherry-pickings... Since stable/12 lags behind on > many other build infrastructure improvements, some commits don't apply > cleanly. So I'm working on this now, and making some progress. The first steps have been to merge everything up to llvm-project 11.0.1. While almost everything in "make universe" works, I have hit one pretty annoying snag: the arm.arm target (aka "armv4"). This has been dropped in FreeBSD 13 and later, due to it being old and missing lots of features, in favor of armv6 and armv7. I have been able to work around things such as missing atomic support, and some other issues. But the big problem with this target is that it was frankenstein'd into using clang as its compiler, while still using the ancient BFD ld 2.17.50! With clang 11 and higher, I quickly ran into issues that this ancient version of BFD ld chokes on ELF files with more than 64k sections, and these are now produced pretty often, especially if you are using -ffunction-sections -fdata-sections. However, C++ programs also emit lots of comdat sections, and due to some arm specific shenanigans, this costs 4 sections per symbol! So any largish C++ program goes over 64k sections, for example clang and lld themselves, but also the googletest suite we have in-tree. I did some spelunking in the binutils git repository, and I found that there is an upstream commit that fixes the 64k sections limit. Unfortunately, this is a big commit that is also under GPLv3, so we cannot import it as-is. And even if we got permission from the original author to use it under GPLv2, it would still not solve the problem that the old BFD ld is *extremely* slow on these files. Case in point, linking clang.full with it took >60 minutes, even on a fairly fast machine! The obvious solution would seem to be to switch to lld as the default linker, however that also runs into a snag. Since lld uses the blx instruction for interworking, it prints a warning "lld uses blx instruction, no object with architecture supporting feature detected". And because we link with the --fatal-warnings option, this stops buildworld dead in its tracks. Obviously, this warning could be ignored (by removing --fatal-warnings, or patching it out), but I think this might result in issues when the actual binaries are run. Unfortunately I have no way to verify whether this is the case, so my current working solution is to switch arm.arm back to good old gcc 4.2.1, which should work fine in combination with the equally ancient BFD ld 2.17.50. Since this combination has bitrotted a little in mean time, it was required to add a few minor patches to the tree to make it build. But I expect the produced binaries should run OK on actual armv4 hardware. So the executive summary is: * clang 11 and higher (up to 13) can most likely be backported to stable/12 * except for arm.arm (armv4) which will have to choose between: 1. clang/ld.lld >11 with possible blx instructions, no idea if this will work on actual hardware 2. gcc/ld.bfd which should always have worked, but no shiny new clang or lld That last option would also mean that many ports can't be built of course. But it seems hardly relevant, as nobody is going to natively build Chromium or Firefox on those low-powered machines? In any case, I would like to solicit some feedback about this, so I can continue merging. Personally my preferred solution would be to switch arm.arm to gcc, so it can deorbit in peace. Otherwise somebody with access to this hardware should verify that a world linked with lld actually runs; that might not be trivial. -Dimitry --Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYcDtVwAKCRCwXqMKLiCW o9ixAJ4hh7kgoAlYR0Vr1odqGIuzyq0GAgCgh+P56nJim8+bX0EjHpTqT/8jSKg= =Yn87 -----END PGP SIGNATURE----- --Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240--