From nobody Mon Aug 05 05:53:32 2024 X-Original-To: freebsd-arm@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 4Wclwv6Gpmz5SbwC; Mon, 05 Aug 2024 05:53:35 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wclwv2ZQRz4Z8g; Mon, 5 Aug 2024 05:53:35 +0000 (UTC) (envelope-from melounmichal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a7a975fb47eso1334379366b.3; Sun, 04 Aug 2024 22:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722837214; x=1723442014; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:from:to:cc:subject:date:message-id:reply-to; bh=a9VpmZnxfzE+HB/3Ol8Iw7RsJ4WAQLGANYaj2/0Tq5o=; b=RtKCN1Ot3fkInxS6TF41HkJwYH3/vf6g4GizQqMhKMAa2liSlpsSxLA1HXYWC06qUC +Oks8h5v5pZ3/EKsPiu90mJMtUO5yZKb7EREqJZlUFuWe0m8Vve7thKNXXkB10TF+WO0 LO+nh4ZtxPiKSCgS802eTTx2orkrqBu9ZN+xjPNKEYKxmHSmnrLA9j26eyeJk9uSJT8Q K6s0EmLvxcJTgSwjKOrropzPxZyG99w6qoP439+I3Q0B3hv5eFFPKupDNRtq0GRS+kPS uQYWNse8hrn5p3Hn1EBZ3vB4wyeC7JMqaU44p3FLF+SxT73V480bmo+wOeM6uyyCG4jP kHkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722837214; x=1723442014; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=a9VpmZnxfzE+HB/3Ol8Iw7RsJ4WAQLGANYaj2/0Tq5o=; b=N9fLs2H8rS3NBxvm4q8cq9lgMFT7oYJaa0v79G7E3CGc3ZiytgtcDnIGFwarKVGxgJ 9Mazc1JIclxRuT+EEEMsJTiEBdEUCDEezUrzF8KrLTK5HN1y8IxJjeqSwf2hGWaOqq13 I6Avmt/MAETmnosb8ZJasKvFW+FwoVpoeOajgWZgETUp3XDJaS55iSupVAOclwE8Q3Vz 3/QL5DL/XrpikIUPJ0jJ8+3jku2NeMVuyDEF/hOyIkQeuafZphdylzxAmlYZHpdD6hIG xGcuSIITfFATPOFfAkLz8AlUwpp8/srCHINzNY6NnugYmG1Y9IyxMa8FDxUlpxMc8E0M wrVA== X-Forwarded-Encrypted: i=1; AJvYcCVjXjWLHlAmLTmPNuZxq6X4p7aOBOd5T1iuhGQ6v4/SxGVSXa4bw7u/5ppMgDeq2SkVoLu6cHhy6bAhw9xjBieVIM2Qxjx8i518jVZNhgFLstg1khwy26AN1WldwRc23byP2XvW10Q= X-Gm-Message-State: AOJu0Yy7iiv/rHNyIfsus1ok4SVHBYp8L/UYZG9o+zs0VNYZSwmwxsb9 CsWRO4ZyHcDuo7X/Nyf37vSnaAiwXMjWyxUJMtNyGoUxbKe4Bl/tFpQpeQ== X-Google-Smtp-Source: AGHT+IEHnHmGSBgB1+6hPNmbk2+vC1v2oKa9ouFS/R8g+LcOS+QS/SVImwg69/SUmramVA3kLvwI2Q== X-Received: by 2002:a17:907:6e9f:b0:a77:d441:c6f1 with SMTP id a640c23a62f3a-a7dc4e6cc2dmr802041666b.33.1722837213105; Sun, 04 Aug 2024 22:53:33 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:7915:12c7:2a9c:641f? ([2001:67c:14a0:5fe0:7915:12c7:2a9c:641f]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9d433fesm412819366b.142.2024.08.04.22.53.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Aug 2024 22:53:32 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Message-ID: Date: Mon, 5 Aug 2024 07:53:32 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@freebsd.org Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? To: Mark Millard , FreeBSD Toolchain , FreeBSD ARM List References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> Content-Language: cs, en-US In-Reply-To: <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Wclwv2ZQRz4Z8g On 04.08.2024 23:31, Mark Millard wrote: > On Aug 3, 2024, at 23:07, Mark Millard wrote: > >> My recent attempts to build devel/llvm18 and devel/llvm19 in an armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures that stop the build and report as: >> >> LLVM ERROR: out of memory >> Allocation failed >> >> (no system OOM activity or notices, so just a process size/fragmentation issue, or so I would expect). >> >> On native armv7 I also had rust 1.79.0 fail that way so --but aarch64-as-armv7 built it okay. >> >> I'm curious if --threads=1 use for the linker might allow the devel/llvm* builds to complete at this point. Similarly for rust. (top showed that the ld activity was multi-threaded.) >> >> Note: The structure of the poudriere-devel based native build attempts is historical and it used to work. Similarly for the aarch64-as-armv7 based build attempts. For now I'd just be exploring changes that might allow much of my historical overall structure to still work. But I expect that things are just growing to the point building is starting to be problematical with process address spaces that are bounded by a limit somewhat under 4 GiBytes. >> >> >> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >> at boot time: >> >> AVAIL_RAM+SWAP == 1958Mi+3685Mi == 5643Mi >> >> and later had "Max(imum)Obs(erved)" figures: >> >> Mem: . . ., >> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi MaxObs(Act+Wir+Lndry) >> >> Swap: 3685Mi Total, . . ., >> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >> >> >> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >> >> AVAIL_RAM+SWAP == 31311Mi+120831Mi == 152142Mi >> >> So lots of 4 GiByte or smaller processes would fit. >> > > Absent finding a way to get --threads=1 to be what is used, I > made the following crude way to test, built it, installed it > in the armv7 directory tree used for aarch64-as-armv7, and > then started an aarch64-as-armv7 test of building devel/llvm19 > to see what the consequences are (leading whitespace details > might not be preserved): > > # git -C /usr/main-src/ diff contrib/llvm-project/ > diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp b/contrib/llvm-project/lld/ELF/Driver.cpp > index 8b2c32b15348..299daf7dd6fa 100644 > --- a/contrib/llvm-project/lld/ELF/Driver.cpp > +++ b/contrib/llvm-project/lld/ELF/Driver.cpp > @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList &args) { > arg->getValue() + "'"); > parallel::strategy = hardware_concurrency(threads); > config->thinLTOJobs = v; > + } else if (sizeof(void*) <= 4) { > + log("set maximum concurrency to 1, specify --threads= to change"); > + parallel::strategy = hardware_concurrency(1); > } else if (parallel::strategy.compute_thread_count() > 16) { > log("set maximum concurrency to 16, specify --threads= to change"); > parallel::strategy = hardware_concurrency(16); > > Basically, if the process address space has to be "small", avoid > any default memory use tradeoffs that multi-threading the linker > might involve --even if that means taking more time. > > We will see if: > > [00:00:33] [07] [00:00:00] Building devel/llvm19@default | llvm19-19.1.0.r1 > > still fails to build as armv7 vs. if the change leads it to > manage to build as armv7. > > === > Mark Millard > marklmi at yahoo.com > I can build llvm18 and rust 1.79 on native armv7 without problems - on Tegra TK1, without poudriere and on the ufs filesystem. IMHO poudriere is unusable on 32bit systems. Michal Meloun