From owner-freebsd-current@freebsd.org Sat Jan 16 15:55:39 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0D80F4E34B3; Sat, 16 Jan 2021 15:55:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJ2h96DrLz4T34; Sat, 16 Jan 2021 15:55:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 10GFtdnj024452 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 16 Jan 2021 07:55:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 10GFtc0Y024451; Sat, 16 Jan 2021 07:55:38 -0800 (PST) (envelope-from fbsd) Date: Sat, 16 Jan 2021 07:55:38 -0800 From: bob prohaska To: Mark Millard Cc: Current FreeBSD , freebsd-arm@freebsd.org Subject: Re: Invoking -v for clang during buildworld Message-ID: <20210116155538.GA24259@www.zefox.net> References: <20210116043740.GA19523@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DJ2h96DrLz4T34 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.55 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.45)[-0.447]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 15:55:39 -0000 On Fri, Jan 15, 2021 at 09:25:00PM -0800, Mark Millard wrote: > > On 2021-Jan-15, at 20:37, bob prohaska wrote: > > > While playing with -current on armv7 using a raspberry pi 2 v1.1 > > an error crops up with recent kernels while building world: > > > > ++: error: linker command failed with exit code 1 (use -v to see invocation) > > *** [clang.full] Error code 1 > > > > make[5]: stopped in /usr/freebsd-src/usr.bin/clang/clang > > > > How does one invoke -v in this situation? > > Going a different direction: Going to publish the build log > someplace? There is likely more there of interest to isolating > the issue(s). > I've put what I hope is a useful picture at http://www.zefox.net/~fbsd/rpi2/buildworld/ Files from a clean start would probably be better, but it will take days to get back to that state. I was thinking this might be a kernel problem, but after trying three different kernels, all with the same result, it's looking doubtful. No hint of the "cannot allocate memory" message of earlier troubles, and nothing on the console. One additional question, however: Does the Pi2 have an internal voltage measurement that could be added to the swap logging script? Sysctl -a | grep olt produces a bunch of output, but none of it looks real, with too many trailing zeroes. Power supply problems have been rare, but they caused much hair loss. RaspiOS reports under voltage, does FreeBSD have a comparable feature? > I use META_MODE builds. One thing they do is record the > command used to try to produce each file. So in that kind > of context, identifying what it was trying to build allows > finding the related NAME.meta file and looking in it. > > An example failure for armv7 and 1 GiByte of RAM could be > a simple memory allocation failure: unable to get a > sufficiently large contiguous range from the address space > for some request. (So it never gets to the point of using > swap for it.) Are you controlling how many threads the > linker uses? > There have been none of the "unable to allocate memory" messages that characterized the previous failures, and nothing on the console. I do not try to control thread count beyond -j4 on the command line. It wasn't necessary up to a few days ago. It does seem that memory use is vastly greater with the arrival of clang 11, swap use on armv7 gets up past half a GB. With clang 9 it hardly registered. > > For the record, uname -a reports > > FreeBSD www.zefox.com 13.0-CURRENT FreeBSD 13.0-CURRENT #6 main-c950-gff1a307801: Wed Jan 13 19:02:18 PST 2021 bob@www.zefox.com:/usr/obj/usr/freebsd-src/arm.armv7/sys/GENERIC-MMCCAM arm > > > > The present sources are a day or two newer. > > > > Nothing is obviously wrong; swap usage is small, no warnings or errors on the console. > > > > In past occurrences, an old kernel (pre-git) worked through the problem. > > If a restart of make buildworld doesn't get past the stoppage I'll check again. The pre-git kernel didn't work either, nor did kernel.old, a couple days previous. For clarity, all three were -DNO_CLEAN starts. Thanks for reading, bob prohaska