From owner-freebsd-current@freebsd.org Sat Jan 16 19:17:59 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 2B8EB4E80D4 for ; Sat, 16 Jan 2021 19:17:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DJ79d57PBz4hX8 for ; Sat, 16 Jan 2021 19:17:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610824675; bh=7K1O44PzxWHYVNMs6VrQ6RSf6cCHiUPCnNvF/6olY4T=; h=Subject:From:Date:To:From:Subject:Reply-To; b=Z+e7BGyQrai0fYPLRTAaDbf3mO5uhUhVkzgilh2ieEZcKCWwxP+94mQ1L4E1JvZq59wn615uROCeOXOE91eLnuDCyk3VzjjTzfX07KkbqEyetvQeSwGau0LPNdxvxamXw3oTePqP5I2y4lg7khZnZ9GfLUSSBGSoavqoT6SRip66BEskQsChcL5hSEsotBfD2CCbCcSSV4+mw8OZ2H3evnT/K34r+s3YAZEmEeZKHTDBhDlOEJypK9yLaO9A2c7HpOb7Fl7s1fRjFFl2mMuZ7RSTSdSWNfIueQDUtUD1+LtW7SXlIpdWMSh5JVzd47lRsBkAcn6TU4J6iFMwTLtP2Q== X-YMail-OSG: XsEnvE0VM1mEbMR60IoIKNUeveLs.0Fp.Um37xEXZG8TjOUUCImKmEwgjbTSlMq ndcaxHzSAUiyruggkrdcPuxjfjUNWKTKMq3dOzlUMGADg72Hl2Q0YfRBroymWz4AIQ8JnUMZbsaU SqS0fkr9.MzaB2e.lmz4aYnpQwgts8S5wNOlLhHVRtHcP90KswIogNpzVHTJKDw9rmtXUC3RIQY_ J.vnEHLYu107IE7D8VrEMxjYw.Dx542IabdoTXu3wHY3AjxTnyKZ2luoF8brMoomTa2u6Lj9Jpk3 Hz_eowNYo3Evu.lJvH6XZ9FnDg3H.XykJqBuLUeSqx151OGG0KP7AnoHDWGX9vcq1XTXAeW654LG 0lBC0pr0_tfvwr.c9ut7G5BOZ2hqFjLSkKDQ1w6SXdy1inNPKmP8FUDTpdvsrvkBPSpHXAYAYOVD oIDKoy1cv_lzXsmxhX1_Anzzrm39hgGIxThmGmFcLDwzJYM.NyICbxt.ZyoaKyAL5.Z32WzTM.DU fNkX5SiX6UurfeLDT0nNkmqorTIQnLpE.sCvwk7cR5WfR5FPog1ISLkceLgklKBo6D2fAWbZWR1o oYquEHT3vDeANIkMh4K4ArDEOKp299pbArMVVa7JVeLP1GQXm0qk4TsGeOAordm00.AsjHPvi4BF 6WhVeDj7WExfuV7QYQMoDHPtscG_6yBTN8klf_c2eir.SymdQgIhhn6UZPbDKf6hJZmeOOuzJPHG woT9J9PAdJthK1l0sRTT9BBIlZc0.PDxKtgo8fph72fPmAdfH2yngLcJd7Rt.pQRChsHthEeOgA5 PPQNbliLHZGFgFY7cO6u82s9SOwU9lFNNWRliKaDZzvpxJs9osNKOCmGH7fBBXCe.4K0aaTGMGwY oAcETzGTbOT99KZFqwPjU4cd5Cj8KmsYOI61zpkfVAlmu.Vw50n7ajLdKcGNF65mvLG1jxJZzeqy BBtYn4HjwGb0Y2_9URMmqprfye2m1jZ6.MRRLMnP9LcBw0tip6C4HfLuzr4_4iRuv_CDO578M8Hn qriufArVTaqH9oUkEbTAsxKREePUbLUS9qfXuAgFqKTbk.wjsDi2PtAsfgqFoRzX0d9Y.Nhn1dZB _j8uYgo4O03cemNvhrwN.sd1QNK970cqKQ1OZSWvqhFvBS75pGlqCXvHDX6ihAZXxYiQ4sOPwrhQ qvNtEAzujNWtTg2t4.9oR_vGWjFh9CVerRQIx1qZNzP79qR8K5GaMH0_FKFeuXJmStaRucdFInYj A5pkSssul15qAIx_pWMim4W.Tp570d_2zfqvX7YJe9kxSoAmaWpI6gAzYP3tPcnOPo2sMFvDPyu7 2roDyJero4mh1XhXr5HuKiYYlRZs9c5AwFo2UpxxNbd0wdCN0bB9QX_oHSWXlf.mGxhXie2hsYxd .F9S_V6cMkgy0NlxVfEenbRESMu98vDoRN89o2yyST8nfnO9jJ0MbXiq5lA1naGipua56aErD3DD x4uln4y8Z2b8XvjWRavBrmnKJHrKKYd5t3r8.j__2sZpW8n3vTdhZybQOtGkgGWEHy6FinLSijLN l76jRRDabcdkXflPbuuddhfF6FbbJQeBYDb_wdEFm6dmx98UJ66VnN5uBzQxtyyPoeNO4NSS.A1o hPfv2VfqxkCyOL1JjA3oTfNjyAZEnrqyjqvON7Aev3nKAAsIph5U996.f8WYPVrMSNNaQZxXvo_h TxC1c.oLKF.Yf18qXO6SI6lYSy2Qaciz6iizr5j6fjB4R3VFTxupkfT4RxM5SeNgaJkfCytkdN1K HAze0dSK5toF9RxzZtYzej9EkPLNtCsiPF538Hl5h880Rt7xLbJQkN5lv6IhkNjd85dhcz73UjxD crTaLNGl8c3EhdjWnXH2jAlyA72pOvWcpg4vqnwsQmn7GgvDjpTT2JEkL5.7w2auy0.0B47CYCkn .NEiARYEEFrf44b0yAgEHdM4vuMFEo5p52YRQkdnhjuYVP4da1TV2bsprgr3EA5TwsrqFOdI78gQ xropCDzYVx6y2xPEAeN4dDRj3eda1DmmecVvCFVaKJCQc6ytWxnPg.VXN9bWZMCWLXOh_wq8i6SV l6WanYqbuAT55aI4EHRsTqCedJOxKxAmjCeBqtNb2ByDH2hOZTjgddUpPZT7dL7X_Nj8hIl81vsA dtE7lSZiy.uexU3teqObnuvGJSasrTqHWxxcE8jsQrQoMTORnOpzOSUeZB21my9C92uFpUlfGFb0 hpxzGLN_2pyx5yU0JXcpQcwF5IQ_CNRONCe2VBjok7E38nAuwhJL5R4NRc3XW_WClJt.TRs9r.ow Q5zgBPzxAlHd8.fpM6.SmlF8Nifa8LmC7X_gaeP6i4MnqN3Q_B0HWGa.EU9Wme16EX3zrwEsrzcR 77tjQVjWSdAynk62PEru17spAzR3Hj1e92xyCLh9amiEfnOTQLgNzBZVtU0u24VsuEKXoTkJPUjE zvEcflFdqo2XBVdMpLw89udcFLT2GLbqJyPtNa8VxkMugAgf0y6_FmOX3SzH5SAw.dmKSU3UryhO Id9id6wLbVcw.32pQpWRNmvVoopEAhsUh6MnlCJqAfcYXWlL1h0lJ7i7UtpyotlKfJp6YKitwoaO dF75Pr22u0Ijf46Y- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jan 2021 19:17:55 +0000 Received: by smtp418.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0fd4da5094f3f3ca59a61d28a1d3b8ef; Sat, 16 Jan 2021 19:17:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Invoking -v for clang during buildworld From: Mark Millard In-Reply-To: <20210116155538.GA24259@www.zefox.net> Date: Sat, 16 Jan 2021 11:17:52 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210116043740.GA19523@www.zefox.net> <20210116155538.GA24259@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DJ79d57PBz4hX8 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.83:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] 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 19:17:59 -0000 On 2021-Jan-16, at 07:55, bob prohaska wrote: > On Fri, Jan 15, 2021 at 09:25:00PM -0800, Mark Millard wrote: >>=20 >> On 2021-Jan-15, at 20:37, bob prohaska wrote: >>=20 >>> While playing with -current on armv7 using a raspberry pi 2 v1.1=20 >>> an error crops up with recent kernels while building world: >>>=20 >>> ++: error: linker command failed with exit code 1 (use -v to see = invocation) >>> *** [clang.full] Error code 1 >>>=20 >>> make[5]: stopped in /usr/freebsd-src/usr.bin/clang/clang >>>=20 >>> How does one invoke -v in this situation? >>=20 >> Going a different direction: Going to publish the build log >> someplace? There is likely more there of interest to isolating >> the issue(s). >>=20 > I've put what I hope is a useful picture at > http://www.zefox.net/~fbsd/rpi2/buildworld/ Looks to me like your -DNO_CLEAN based build is reusing one or more files with inappropriate/incomplete contents that need to be regenerated: there are a number of undefined symbols stopping the linker during its attempt to build the "usr.bin/clang/clang (all)" material. See below. --- all_subdir_usr.bin --- --- all_subdir_usr.bin/clang --- =3D=3D=3D> usr.bin/clang (all) --- all_subdir_lib --- --- all_subdir_lib/libbsm --- =3D=3D=3D> lib/libbsm (all) --- all_subdir_usr.bin --- --- all_subdir_usr.bin/clang/clang --- =3D=3D=3D> usr.bin/clang/clang (all) . . . --- all_subdir_usr.bin --- ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::CodeGenTBAA(clang::ASTContext&, = llvm::Module&, clang::CodeGenOptions const&, clang::LangOptions const&, = clang::MangleContext&) >>> referenced by CodeGenModule.cpp:148 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :148) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::CodeGenModule(clang::ASTCo= ntext&, clang::HeaderSearchOptions const&, clang::PreprocessorOptions = const&, clang::CodeGenOptions const&, llvm::Module&, = clang::DiagnosticsEngine&, clang::CoverageSourceInfo*)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: clang::CodeGen::CodeGenTBAA::~CodeGenTBAA() >>> referenced by memory:2262 = (/usr/obj/usr/freebsd-src/arm.armv7/tmp/usr/include/c++/v1/memory:2262) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::CodeGenModule(clang::ASTCo= ntext&, clang::HeaderSearchOptions const&, clang::PreprocessorOptions = const&, clang::CodeGenOptions const&, llvm::Module&, = clang::DiagnosticsEngine&, clang::CoverageSourceInfo*)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a >>> referenced by memory:2262 = (/usr/obj/usr/freebsd-src/arm.armv7/tmp/usr/include/c++/v1/memory:2262) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::~CodeGenModule()) in = archive /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::getTypeInfo(clang::QualType) >>> referenced by CodeGenModule.cpp:706 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :706) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::getTBAATypeInfo(clang::Qua= lType)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::getAccessInfo(clang::QualType) >>> referenced by CodeGenModule.cpp:725 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :725) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::getTBAAAccessInfo(clang::Q= ualType)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::getVTablePtrAccessInfo(llvm::Type*) >>> referenced by CodeGenModule.cpp:732 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :732) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::getTBAAVTablePtrAccessInfo= (llvm::Type*)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::getTBAAStructInfo(clang::QualType) >>> referenced by CodeGenModule.cpp:738 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :738) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::getTBAAStructInfo(clang::Q= ualType)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::getBaseTypeInfo(clang::QualType) >>> referenced by CodeGenModule.cpp:744 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :744) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::getTBAABaseTypeInfo(clang:= :QualType)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::mergeTBAAInfoForCast(clang::CodeGen::TBAAAcce= ssInfo, clang::CodeGen::TBAAAccessInfo) >>> referenced by CodeGenModule.cpp:757 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :757) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::mergeTBAAInfoForCast(clang= ::CodeGen::TBAAAccessInfo, clang::CodeGen::TBAAAccessInfo)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::mergeTBAAInfoForConditionalOperator(clang::Co= deGen::TBAAAccessInfo, clang::CodeGen::TBAAAccessInfo) >>> referenced by CodeGenModule.cpp:765 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :765) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::mergeTBAAInfoForConditiona= lOperator(clang::CodeGen::TBAAAccessInfo, = clang::CodeGen::TBAAAccessInfo)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a >>> referenced by CodeGenModule.cpp:773 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :773) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::mergeTBAAInfoForMemoryTran= sfer(clang::CodeGen::TBAAAccessInfo, clang::CodeGen::TBAAAccessInfo)) in = archive /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a ld: error: undefined symbol: = clang::CodeGen::CodeGenTBAA::getAccessTagInfo(clang::CodeGen::TBAAAccessIn= fo) >>> referenced by CodeGenModule.cpp:750 = (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp= :750) >>> = CodeGenModule.o:(clang::CodeGen::CodeGenModule::DecorateInstructionWithTBA= A(llvm::Instruction*, clang::CodeGen::TBAAAccessInfo)) in archive = /usr/obj/usr/freebsd-src/arm.armv7/lib/clang/libclang/libclang.a FYI: I found this by noting the "all_subdir_usr.bin" below and searching backwards for prior examples and seeing what was after those examples. --- all_subdir_usr.bin --- c++: error: linker command failed with exit code 1 (use -v to see = invocation) *** [clang.full] Error code 1 > Files from a clean start would probably be better, It may be possible to be more selective about deleting things so that just those are regenerated. But, fundamentally the problem seems to be -DNO_CLEAN not rebuilding at least one file that needs to be rebuilt. > but it will take=20 > days to get back to that state. Yep. If you can figure out what file should contain the likes of clang::CodeGen::CodeGenTBAA::CodeGenTBAA material and=20 delete that file, it should be regenerated. But there may be more files that are not correctly built that may or may not be such that an error would be reported. > I was thinking this might be a=20 > 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.=20 The undefined symbols seem unlikely to be a kernel problem. > 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? =20 The undefined symbols seem unlikely to be a voltage problem. The zeros are from the units for the integers not being volts but micro volts. (Which is not the same as saying measurements reach that scale of accuracy.) >> 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. >>=20 >> 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? >>=20 > There have been none of the "unable to allocate memory" messages > that characterized the previous failures, and nothing on the console.=20= Agreed. Although the missing symbols could be from prior partial updates of a file from a prior crash. (I've no specific evidence that such is what actually happened.) > 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.=20 I noticed disabled use of controlling linker thread usage in both e/tc/src.conf and /etc/make/conf: #LDFLAGS.lld+=3D -Wl,--threads=3D1 But I've no specific evidence of memory allocation based failures in this run or prior build attempts that contribute to the current status for -DNO_CLEAN. >>> 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 >>>=20 >>> The present sources are a day or two newer. >>>=20 >>> Nothing is obviously wrong; swap usage is small, no warnings or = errors on the console. >>>=20 >>> 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. I see no specific evidence for a kernel problem being involved. > The pre-git kernel didn't work either, nor did kernel.old, a couple = days > previous. For clarity, all three were -DNO_CLEAN starts. >=20 I see no specific evidence for a kernel problem being involved. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)