Date: Sat, 16 Jan 2021 07:55:38 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: Current FreeBSD <freebsd-current@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: Invoking -v for clang during buildworld Message-ID: <20210116155538.GA24259@www.zefox.net> In-Reply-To: <ED26508F-282D-439D-8A6A-65A136C76C84@yahoo.com> References: <20210116043740.GA19523@www.zefox.net> <ED26508F-282D-439D-8A6A-65A136C76C84@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 15, 2021 at 09:25:00PM -0800, Mark Millard wrote: > > On 2021-Jan-15, at 20:37, bob prohaska <fbsd at www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210116155538.GA24259>