On 2021-Jan-16, at 07:55, bob prohaska <fbsd at www.zefox.net> wrote: > 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/ 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 --- ===> usr.bin/clang (all) --- all_subdir_lib --- --- all_subdir_lib/libbsm --- ===> lib/libbsm (all) --- all_subdir_usr.bin --- --- all_subdir_usr.bin/clang/clang --- ===> 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::ASTContext&, 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::ASTContext&, 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::QualType)) 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::QualType)) 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::QualType)) 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::TBAAAccessInfo, 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::CodeGen::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::mergeTBAAInfoForConditionalOperator(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::mergeTBAAInfoForMemoryTransfer(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::TBAAAccessInfo) >>> referenced by CodeGenModule.cpp:750 (/usr/freebsd-src/contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:750) >>> CodeGenModule.o:(clang::CodeGen::CodeGenModule::DecorateInstructionWithTBAA(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 > 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 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 > 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. 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? 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. >> >> 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. 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. I noticed disabled use of controlling linker thread usage in both e/tc/src.conf and /etc/make/conf: #LDFLAGS.lld+= -Wl,--threads=1 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_at_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. 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. > I see no specific evidence for a kernel problem being involved. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Sat Jan 16 2021 - 18:17:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC