From owner-freebsd-arm@freebsd.org Sat May 21 18:44:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90D7EB443F3 for ; Sat, 21 May 2016 18:44:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 41E771715; Sat, 21 May 2016 18:44:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id u4LIiNRt048026 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 May 2016 11:44:24 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id u4LIiNEX048025; Sat, 21 May 2016 11:44:23 -0700 (PDT) (envelope-from fbsd) Date: Sat, 21 May 2016 11:44:22 -0700 From: bob prohaska To: Ian Lepore Cc: freebsd-arm Subject: Re: upgrading arm6hf Message-ID: <20160521184422.GN1049@www.zefox.net> References: <20160520065945.GH1049@www.zefox.net> <1463776364.1180.340.camel@freebsd.org> <20160520231622.GI1049@www.zefox.net> <20160521002859.GJ1049@www.zefox.net> <1463795214.1180.351.camel@freebsd.org> <20160521021227.GK1049@www.zefox.net> <1463797063.1180.354.camel@freebsd.org> <20160521023515.GA15151@bluezbox.com> <20160521155043.GM1049@www.zefox.net> <1463849864.1180.364.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463849864.1180.364.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 18:44:23 -0000 On Sat, May 21, 2016 at 10:57:44AM -0600, Ian Lepore wrote: > > Do you have anything (expecially CFLAGS or CPUTYPE) in make.conf or > src.conf? > > My buildworld died overnight on a clang segfault that seems to have > nothing to do with anything, except maybe a kernel memory management > bug or something. I started it up again and it has progressed past the > segfault point, but hasn't gotten as far yet as where yours died. Seemingly not, root@www:/usr/src # svnlite status . ? buildscript ? buildworld.log M share/i18n/esdb/DEC/DECHanyu.src M share/i18n/esdb/KOI/KOI7-switched.src M sys/arm/conf/RPI2 ? sys/modules/Makefile.old root@www:/usr/src # My only tweak was to the kernel config file, adding ucom and uplcom (which seemed to make absolutely no difference in pl2303 behavior). I did try to update src to 300374 and restart buildworld. It stopped again in (I think) a similar way: /usr/include/c++/v1/vector:432: relocation truncated to fit: R_ARM_CALL against symbol `memset' defined in .text section in /usr/lib/libc.a(memset.o) cc1_main.o: In function `~IntrusiveRefCntPtr': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:53: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o) cc1_main.o: In function `clang::CompilerInstance::getInvocation()': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Frontend/CompilerInstance.h:228: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o) cc1_main.o: In function `clang::CompilerInstance::getDiagnostics() const': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Frontend/CompilerInstance.h:330: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o) cc1_main.o: In function `LLVMErrorHandler(void*, std::__1::basic_string, std::__1::allocator > const&, bool)': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:58: relocation truncated to fit: R_ARM_CALL against symbol `exit' defined in .text section in /usr/lib/libc.a(exit.o) cc1_main.o: In function `clang::DiagnosticsEngine::Report(unsigned int)': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.h:1119: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o) cc1_main.o: In function `ForcePassLinking': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/LinkAllPasses.h:55: relocation truncated to fit: R_ARM_CALL against symbol `getenv' defined in .text section in /usr/lib/libc.a(getenv.o) cc1_main.o: In function `Twine': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/ADT/Twine.h:274:--More relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o) cc1_main.o: In function `llvm::iplist >::remove(llvm::ilist_iterator&)': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/ADT/ilist.h:485: relocation truncated to fit: R_ARM_CALL against symbol `__assert' defined in .text section in /usr/lib/libc.a(assert.o) cc1_main.o: In function `llvm::MallocAllocator::Allocate(unsigned int, unsigned int)': /usr/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/Support/Allocator.h:95: additional relocation overflows omitted from the output c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [clang.full] Error code 1 make[4]: stopped in /usr/src/usr.bin/clang/clang 1 error make[4]: stopped in /usr/src/usr.bin/clang/clang *** [all_subdir_usr.bin/clang/clang] Error code 2 make[3]: stopped in /usr/src/usr.bin/clang 1 error Would it make any sense to back down to the pre-hardfloat kernel and try again? My feeling is "no", but unless there's much to lose it's an easy experiment. bob prohaska