ports-mgmt/poudriere-devel, lang/rust (for example), and USE_TMPFS that includes wrkdir (or yes)
I've been using USE_TMPFS=yes (so "wrkdir data") on various systems, both ZFS (recently) and UFS (generally, even now). Only one system builds rust (in order for something else to be built), at least so far. An example of the wrkdirs tmpfs use for rust is (UFS context): # df -m | grep tmpfs Filesystem 1M-blocks Used Avail Capacity Mounted on . . . tmpfs 301422 17859 283563 6% /usr/local/poudriere/data/.m/FBSDFSSDjail-default/01/wrkdirs . . . This was near the end but the maximum figure was probably somewhat higher than the 17 GiByte+ figure above. The context the example is from is for the only large capacity build machine that I have access to, an amd64 context. I have other build contexts as well, but, so far, none have had to deal with building rust. Rust likely would fit the 8 GiByte RAM + 24 GiByte swap aarch64 build context with USE_TMPFS including wrkdir if it was the only builder running at the time. But the existing builds for the context allow 4 builders in parallel, one per core. [This deals just fine with llvm10, llvm11, llvm12, and, gcc10 (no bootstrap) being what happens to build in parallel, even with USE_TMPFS that includes wrkdir. Rust is just uses more space all by itself.] If I end up with something that requires rust for the aarch64 builder context, is there a different technique to deal with the tradeoff other than giving up on USE_TMPFS spanning wrkdir for all other other ports/builder-instances as well, presuming the same media and partitioning (such as total swap space)? Imaginary examples could be: A) Tell poudriere that lang/rust is to be built by itself despite the general 4-builder context. B) Tell poudriere that USE_TMPFS excludes wrkdir for lang/rust's specific builder. C) . . . (good question) . . . So far all I've come up with is explicitly building lang/rust by itself first, a form of (A): # poudriere bulk -jNAME -w lang/rust # poudriere bulk -jNAME -w -f ~/origins/CA72-origins.txt (Hopefully, reliably remembering to do so.) Is there any better technique that I've not noticed? To some extent here, lang/rust is being used an example of a more general issue: Other ports could have similar issues with attempted wrkdir-included USE_TMPFS use. Note: If I build using WITH_DEBUG, the one system that I have access to that can build such a lang/rust with workdir included in USE_TMPFS shows over 130 GiBytes in the tmpfs earn the end of the builder's activity. (This is a amd64 context with 128 GiBytes of RAM and 192 GiBytes of swapping/paging space.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set
On 2021-Apr-8, at 10:46, Mark Millard wrote: > Building devel/llvm10 via poudriere-devel on a Cortex-A57 > system (OverDrive 1000), I ended up with just: > > # /usr/local/llvm10/bin/llc -version > LLVM (http://llvm.org/): > LLVM version 10.0.1 > Optimized build. > Default target: aarch64-portbld-freebsd14.0 > Host CPU: (unknown) > > Registered Targets: >amdgcn - AMD GCN GPUs >r600 - AMD GPUs HD2XXX-HD6XXX > > from a context that has: > > # grep -r BE /usr/local/etc/poudriere.d/options/devel_llvm10/ > /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU > CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE > BE_STANDARD > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD > > (I've used the combination in various llvm*'s for years, > including using such for llvm10. Something has changed.) > > I'll not repeat the material here but llvm11 got the same > sort of result. > > May be that "Host CPU: (unknown)" has something to do with > it? > > This has been true since I built and installed back on > 2021-Feb-11 and is true of my updating build started > yesterday (bulk still in progress). LLVM10 pkg info > from active install: > > # pkg info llvm10 > llvm10-10.0.1_5 > Name : llvm10 > Version: 10.0.1_5 > Installed on : Thu Feb 11 12:05:43 2021 PST > Origin : devel/llvm10 > Architecture : FreeBSD:14:aarch64 > Prefix : /usr/local > Categories : devel lang > Licenses : MIT, BSD3CLAUSE, PD, LLVM, REGEX, LLVM2 > Maintainer : bro...@freebsd.org > WWW: http://llvm.org/ > Comment: LLVM and Clang > Options: > BE_AMDGPU : on > BE_FREEBSD : off > BE_NATIVE : on > BE_STANDARD: off > CLANG : on > DOCS : on > EXTRAS : on > LIT: on > LLD: on > LLDB : on > LLD_LINK : on > OPENMP : on > PYCLANG: off > Shared Libs required: > libedit.so.0 > liblua-5.2.so > libpython3.7m.so.1.0 > libxml2.so.2 > Shared Libs provided: > libRemarks.so.10 > libarcher.so > libclang-cpp.so.10 > liblldb.so.10 > libLTO.so.10 > libLLVM-10.so > libomptarget.so > libomp.so > libclang.so.10 > Annotations: > FreeBSD_version: 144 > repo_type : binary > repository : custom > Flat size : 509MiB > Description: > The LLVM Project is a collection of modular and reusable compiler and > toolchain technologies. > > This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker), > LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure > these are built on. > > WWW: http://llvm.org/ > > > (So the above predates the git conversion.) > > The issue was first noticed via build failures like (from a > log file): > > . . . > Sanity testing C compiler: /usr/local/bin/clang10 > Is cross compiler: False. > Sanity check compiler command line: /usr/local/bin/clang10 > /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.c > -o > /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.exe > -O2 -pipe -mcpu=cortex-a57 -g -fstack-protector-strong -fno-strict-aliasing > -mcpu=cortex-a57 -pipe -D_FILE_OFFSET_BITS=64 -Wl,-rpath=/usr/local/llvm10/lib > Sanity check compile stdout: > > - > Sanity check compile stderr: > error: unable to create target: 'No available targets are compatible with > triple "aarch64-portbld-freebsd14.0"' > 1 error generated. > . . . > > > The FreeBSD is a non-debug build based on main 7381bbee29df: > > # ~/fbsd-based-on-what-freebsd-main.sh > FreeBSD FBSDCA57 14.0-CURRENT FreeBSD 14.0-CURRENT > mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 145 145 > def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git > context. > merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 > merge-base: CommitDate: 2021-03-12 20:29:42 + > 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all > XPT_ASYNC ccbs in a dedicated thread > n245444 (--first-parent --count for merge-base) Using OPTIONS_FILE_SET+=BE_STANDARD instead of OPTIONS_FILE_SET+=BE_NATIVE did not have this problem. (I've not tried BE_FREEBSD so far.) Also, my Cortex-A7 (so: armv7) context did not have the "amdgcn/r600 only" problem with OPTIONS_FILE_SET+=BE_NATIVE : # /usr/local/llvm10/bin/llc -version LLVM (http://llvm.org/): LLVM version 10.0.1 Optimized build. Default t
devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set
Building devel/llvm10 via poudriere-devel on a Cortex-A57 system (OverDrive 1000), I ended up with just: # /usr/local/llvm10/bin/llc -version LLVM (http://llvm.org/): LLVM version 10.0.1 Optimized build. Default target: aarch64-portbld-freebsd14.0 Host CPU: (unknown) Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX from a context that has: # grep -r BE /usr/local/etc/poudriere.d/options/devel_llvm10/ /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD (I've used the combination in various llvm*'s for years, including using such for llvm10. Something has changed.) I'll not repeat the material here but llvm11 got the same sort of result. May be that "Host CPU: (unknown)" has something to do with it? This has been true since I built and installed back on 2021-Feb-11 and is true of my updating build started yesterday (bulk still in progress). LLVM10 pkg info from active install: # pkg info llvm10 llvm10-10.0.1_5 Name : llvm10 Version: 10.0.1_5 Installed on : Thu Feb 11 12:05:43 2021 PST Origin : devel/llvm10 Architecture : FreeBSD:14:aarch64 Prefix : /usr/local Categories : devel lang Licenses : MIT, BSD3CLAUSE, PD, LLVM, REGEX, LLVM2 Maintainer : bro...@freebsd.org WWW: http://llvm.org/ Comment: LLVM and Clang Options: BE_AMDGPU : on BE_FREEBSD : off BE_NATIVE : on BE_STANDARD: off CLANG : on DOCS : on EXTRAS : on LIT: on LLD: on LLDB : on LLD_LINK : on OPENMP : on PYCLANG: off Shared Libs required: libedit.so.0 liblua-5.2.so libpython3.7m.so.1.0 libxml2.so.2 Shared Libs provided: libRemarks.so.10 libarcher.so libclang-cpp.so.10 liblldb.so.10 libLTO.so.10 libLLVM-10.so libomptarget.so libomp.so libclang.so.10 Annotations: FreeBSD_version: 144 repo_type : binary repository : custom Flat size : 509MiB Description: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker), LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure these are built on. WWW: http://llvm.org/ (So the above predates the git conversion.) The issue was first noticed via build failures like (from a log file): . . . Sanity testing C compiler: /usr/local/bin/clang10 Is cross compiler: False. Sanity check compiler command line: /usr/local/bin/clang10 /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.c -o /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.exe -O2 -pipe -mcpu=cortex-a57 -g -fstack-protector-strong -fno-strict-aliasing -mcpu=cortex-a57 -pipe -D_FILE_OFFSET_BITS=64 -Wl,-rpath=/usr/local/llvm10/lib Sanity check compile stdout: - Sanity check compile stderr: error: unable to create target: 'No available targets are compatible with triple "aarch64-portbld-freebsd14.0"' 1 error generated. . . . The FreeBSD is a non-debug build based on main 7381bbee29df: # ~/fbsd-based-on-what-freebsd-main.sh FreeBSD FBSDCA57 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 145 145 def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 merge-base: CommitDate: 2021-03-12 20:29:42 + 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread n245444 (--first-parent --count for merge-base) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
/usr/lib/libomp.so : is there a reason that aarch64 does not have such by default?
My context: head ( currently at -r363590 ) man src.conf is explicit that WITHOUT_OPENMP is the default for aarch64 (for example). But I note that https://openmp.llvm.org/README.txt says: (it has the more detailed breakdown of OS/compiler combinations for architectures where it matters) QUOTE Architectures Supported === * IA-32 architecture * Intel(R) 64 architecture * Intel(R) Many Integrated Core Architecture * ARM* architecture * Aarch64 (64-bit ARM) architecture * IBM(R) Power architecture (big endian) * IBM(R) Power architecture (little endian) * MIPS and MIPS64 architectures * RISC-V 64 bit architecture Supported RTL Build Configurations == Supported Architectures: IA-32 architecture, Intel(R) 64, and Intel(R) Many Integrated Core Architecture -- | icc/icl |gcc | clang | --|---|| | Linux* OS | Yes(1,5)| Yes(2,4) | Yes(4,6,7) | | FreeBSD*| No | No | Yes(4,6,7,8) | | OS X* | Yes(1,3,4) | No | Yes(4,6,7) | | Windows* OS | Yes(1,4)| No | No | . . . (7) Clang* currently does not offer a software-implemented 128 bit extended precision type. Thus, all entry points reliant on this type are removed from the library and cannot be called in the user program. The following functions are not available: __kmpc_atomic_cmplx16_* __kmpc_atomic_float16_* __kmpc_atomic_*_fp . . . Supported Architectures: IBM(R) Power 7 and Power 8 - | gcc | clang | --||--| | Linux* OS | Yes(1,2) | Yes(3,4) | --- . . . ENDQUOTE Nothing stands out for why WITH_OPENMP is in use by default only for amd64, i386, and powerpc64. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
CPU_FFS, its ffsl use, and the need for including if using "ISO" compiler modes
In a aarch64 head -r363590 context with g++9 from ports in use (so ffsl is only compiler-defined outside strict ISO modes) . . . I got a compile failure for using CPU_FFS because ffsl "was not declared". My code was being compiled via -std=c++17 . (Other than enabling one feature, it is not system specific code overall.) Well, it turns out that /usr/include/sys/bitset.h is indirectly used by /usr/include/sys/cpuset.h and bitset.h has use of ffsl in BIT_FFS but bitset.h does nothing to cause use of a: #include to pick up the FreeBSD's libc declaration of the ffsl routine. (There are other "bit string" routines with similar issues.) Nor does "man 2 cpuset" or /usr/include/sys/cpuset.h or /usr/include/sys/bitset.h explicitly suggest the potential need for including to declare things used by the header files that are mentioned in those places. I'll note that g++10 did not object before this change. But I had reason to also build using g++9 . [Compiling the -updated code with g++10 did not complain. Nor did linking the results complain.] Note: The c++17 code involved is not part of a FreeBSD port. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64: unable to use lang/gcc10 to use system libc++ . . . [ unless I use -mno-outline-atomics for gcc10's 10.1 and later]
On 2020-Aug-4, at 16:52, Mark Millard wrote: > On 2020-Aug-4, at 14:27, Mark Millard wrote: >> >> Historically I've been able to use lang/gcc9 to build personal >> aarch64 c++17 applications that used head's libc++ and the >> like (other than some floating point support code for aarch64). >> The redirection of g++9 to system libraries and such looks >> like: >> >> . . . >> CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 >> -I/usr/include >> . . . >> LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ >> -Wl,-rpath=/usr/local/lib/gcc9 >> . . . >> # Note: FreeBSD's libgcc_s were missing at least a floating point routine. >> # The -Wl,-rpath=/usr/local/lib/gcc9 causes use of gcc9's libgcc_s . >> # So far I've only had the issue for targeting aarch64 and armv7. >> . . . >> >> I do not know if there is an intention to allow such things vs. if >> I was just lucky that it worked at the time. Historically I've done >> the same on powerpc64, 32-bit powerpc, and amd64 as well. On those no >> -Wl,-rpath=... was required. Targeting armv7 did require use of >> -Wl,-rpath=/usr/local/lib/gcc9 . >> >> >> >> I've just tried the same sort of thing for using lang/gcc10 and >> targeting aarch64 and it fails to build: >> >> CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 >> -I/usr/include >> . . . >> LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ >> -Wl,-rpath=/usr/local/lib/gcc10 >> >> It ended up failing for: >> >> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function >> `long std::__1::__libcpp_atomic_refcount_decrement(long&)': >> /usr/include/c++/v1/memory:3386: undefined reference to >> `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function >> `long std::__1::__libcpp_atomic_refcount_increment(long&)': >> /usr/include/c++/v1/memory:3375: undefined reference to >> `__aarch64_ldadd8_relax' >> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function >> `long std::__1::__libcpp_atomic_refcount_decrement(long&)': >> /usr/include/c++/v1/memory:3386: undefined reference to >> `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to >> `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to >> `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to >> `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to >> `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: >> ../objs/cpp_clockinfo-g++_10_O3-libc++.o:/usr/include/c++/v1/memory:3386: >> more undefined references to `__aarch64_ldadd8_acq_rel' follow >> collect2: error: ld returned 1 exit status >> *** Error code 1 >> >> Stop. >> make: stopped in /root/acpphint/acpphint_src >> >> (Omitting -Wl,-rpath=/usr/local/lib/gcc10 made no difference.) >> >> I did not have such an issue for powerpc64. I've not tried the >> other platforms yet. >> >> >> Anyone know if I'm out in "if it hurts, then do not do that" >> land? Or is this something that should be possible but is >> currently broken? >> >> >> Note: The C++ source in question tries to be pure C++17 compliant >> code for normal builds. (And I was doing a normal build: no FreeBSD >> specific code or the like enabled.) > > I just tried lang/gcc9 ( -r543890 ports ) on a head -r363590 > aarch64 based system, without -Wl,-rpath=/usr/local/lib/gcc9 > used, and it still builds but at run-time programs get the > likes of: > > ld-elf.so.1: > /root/acpphint/acpphint_kernelsurveyors_main-RPi4B-4096MiB-threads_4-LP64-FreeBSD_13_r363590M_64bit-g++_9_O3-libc++: > Undefined symbol "__floatunditf@GCC_4.2.0" > > So that has not changed. This is a very different issue than > what attempting to use lang/gcc10 gets. > I finally figured out what is going on as of gcc10.1 and later for aarch64: -moutline-atomics is now the default in gcc10.1 and later for aarch64 but FreeBSD is not set up for such as far as I can tell. (Outlined atomics dynamically detect later-added instructions being available and use them instead of the original code sequences that are required on the older aarch64 hardware. On the older hardware they do things the old way.) To get the older style of code generation that avoids needing to have an implementation of the outlined atomics, I've added use of -mno-outline-atomics for aarch64. For example, for avoiding use of gcc's libraries for the most part: CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include OPT=-O3 -mcpu=cortex-a53 -mno-outline-atomics . . . LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ -Wl,-rpath=/usr/local/lib/gcc10 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: aarch64: unable to use lang/gcc10 to use system libc++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing
On 2020-Aug-4, at 14:27, Mark Millard wrote: > > Historically I've been able to use lang/gcc9 to build personal > aarch64 c++17 applications that used head's libc++ and the > like (other than some floating point support code for aarch64). > The redirection of g++9 to system libraries and such looks > like: > > . . . > CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 > -I/usr/include > . . . > LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ >-Wl,-rpath=/usr/local/lib/gcc9 > . . . > # Note: FreeBSD's libgcc_s were missing at least a floating point routine. > # The -Wl,-rpath=/usr/local/lib/gcc9 causes use of gcc9's libgcc_s . > # So far I've only had the issue for targeting aarch64 and armv7. > . . . > > I do not know if there is an intention to allow such things vs. if > I was just lucky that it worked at the time. Historically I've done > the same on powerpc64, 32-bit powerpc, and amd64 as well. On those no > -Wl,-rpath=... was required. Targeting armv7 did require use of > -Wl,-rpath=/usr/local/lib/gcc9 . > > > > I've just tried the same sort of thing for using lang/gcc10 and > targeting aarch64 and it fails to build: > > CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 > -I/usr/include > . . . > LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ >-Wl,-rpath=/usr/local/lib/gcc10 > > It ended up failing for: > > /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function > `long std::__1::__libcpp_atomic_refcount_decrement(long&)': > /usr/include/c++/v1/memory:3386: undefined reference to > `__aarch64_ldadd8_acq_rel' > /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function > `long std::__1::__libcpp_atomic_refcount_increment(long&)': > /usr/include/c++/v1/memory:3375: undefined reference to > `__aarch64_ldadd8_relax' > /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function > `long std::__1::__libcpp_atomic_refcount_decrement(long&)': > /usr/include/c++/v1/memory:3386: undefined reference to > `__aarch64_ldadd8_acq_rel' > /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to > `__aarch64_ldadd8_acq_rel' > /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to > `__aarch64_ldadd8_acq_rel' > /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to > `__aarch64_ldadd8_acq_rel' > /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to > `__aarch64_ldadd8_acq_rel' > /usr/local/bin/ld: > ../objs/cpp_clockinfo-g++_10_O3-libc++.o:/usr/include/c++/v1/memory:3386: > more undefined references to `__aarch64_ldadd8_acq_rel' follow > collect2: error: ld returned 1 exit status > *** Error code 1 > > Stop. > make: stopped in /root/acpphint/acpphint_src > > (Omitting -Wl,-rpath=/usr/local/lib/gcc10 made no difference.) > > I did not have such an issue for powerpc64. I've not tried the > other platforms yet. > > > Anyone know if I'm out in "if it hurts, then do not do that" > land? Or is this something that should be possible but is > currently broken? > > > Note: The C++ source in question tries to be pure C++17 compliant > code for normal builds. (And I was doing a normal build: no FreeBSD > specific code or the like enabled.) I just tried lang/gcc9 ( -r543890 ports ) on a head -r363590 aarch64 based system, without -Wl,-rpath=/usr/local/lib/gcc9 used, and it still builds but at run-time programs get the likes of: ld-elf.so.1: /root/acpphint/acpphint_kernelsurveyors_main-RPi4B-4096MiB-threads_4-LP64-FreeBSD_13_r363590M_64bit-g++_9_O3-libc++: Undefined symbol "__floatunditf@GCC_4.2.0" So that has not changed. This is a very different issue than what attempting to use lang/gcc10 gets. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
aarch64: unable to use lang/gcc10 to use system libc++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing
Historically I've been able to use lang/gcc9 to build personal aarch64 c++17 applications that used head's libc++ and the like (other than some floating point support code for aarch64). The redirection of g++9 to system libraries and such looks like: . . . CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include . . . LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ -Wl,-rpath=/usr/local/lib/gcc9 . . . # Note: FreeBSD's libgcc_s were missing at least a floating point routine. # The -Wl,-rpath=/usr/local/lib/gcc9 causes use of gcc9's libgcc_s . # So far I've only had the issue for targeting aarch64 and armv7. . . . I do not know if there is an intention to allow such things vs. if I was just lucky that it worked at the time. Historically I've done the same on powerpc64, 32-bit powerpc, and amd64 as well. On those no -Wl,-rpath=... was required. Targeting armv7 did require use of -Wl,-rpath=/usr/local/lib/gcc9 . I've just tried the same sort of thing for using lang/gcc10 and targeting aarch64 and it fails to build: CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include . . . LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ -Wl,-rpath=/usr/local/lib/gcc10 It ended up failing for: /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function `long std::__1::__libcpp_atomic_refcount_decrement(long&)': /usr/include/c++/v1/memory:3386: undefined reference to `__aarch64_ldadd8_acq_rel' /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function `long std::__1::__libcpp_atomic_refcount_increment(long&)': /usr/include/c++/v1/memory:3375: undefined reference to `__aarch64_ldadd8_relax' /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in function `long std::__1::__libcpp_atomic_refcount_decrement(long&)': /usr/include/c++/v1/memory:3386: undefined reference to `__aarch64_ldadd8_acq_rel' /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to `__aarch64_ldadd8_acq_rel' /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to `__aarch64_ldadd8_acq_rel' /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to `__aarch64_ldadd8_acq_rel' /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined reference to `__aarch64_ldadd8_acq_rel' /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o:/usr/include/c++/v1/memory:3386: more undefined references to `__aarch64_ldadd8_acq_rel' follow collect2: error: ld returned 1 exit status *** Error code 1 Stop. make: stopped in /root/acpphint/acpphint_src (Omitting -Wl,-rpath=/usr/local/lib/gcc10 made no difference.) I did not have such an issue for powerpc64. I've not tried the other platforms yet. Anyone know if I'm out in "if it hurts, then do not do that" land? Or is this something that should be possible but is currently broken? Note: The C++ source in question tries to be pure C++17 compliant code for normal builds. (And I was doing a normal build: no FreeBSD specific code or the like enabled.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) (LLVMgold.so and gnu's ld.gold)
On 2020-Jul-25, at 13:59, Mark Millard wrote:
> On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
>
>> Am 08.07.20 um 09:01 schrieb Mark Millard:
>>> The following is more informational than anything as far
>>> as I'm concerned. But there may be implications that I'm
>>> unaware of. (I sometimes experiment with toolchain use
>>> to see what the current status is for such use.)
>>>
>>> I attempted to build a system for 32-bit powerpc using clang
>>> and binutils, building head -r363000 ( from -r363000 ). (This
>>> was a cross build, amd64 -> powerpc.) It got a new type of
>>> failure, compared to my past experience:
>>
>> Hi Mark,
>>
>> thank you for the report. I have tested with "make universe" (with
>> default settings) that this version builds on all architectures,
>> but Ed Maste has already disabled -flto for powerpc64, due to run
>> time issues (floating point exception, IIRC).
>>
>> I know that you are actively working on PowerPC and I'd appreciate,
>> if you could provide me with information on which parameters cause
>> breakage and which work for you. The combination of CLANG with LTO
>> and GNU binutils cannot work - CLANG and GCC use incompatible file
>> formats to represent the intermediate object files.
>
> Hmm. It looks a little more complicated than that . . .
>
> Looks like the devel/llvm80 devel/llvm90 and devel/llvm10
> options for powerpc64 include one for:
>
> GOLD=on: Build the LLVM Gold plugin for LTO
>
> That produces a plugin (LLVMgold.so) for use with gnu's
> ld.gold ( from devel/binutils ).
>
> . . .
Ignore those notes. It looks like I greatly misinterpreted. For
example doing some personal software builds with -flto in use
resulted in (using devel/llvm11 as an example context):
(powerpc64 context used)
"/usr/local/llvm11/bin/ld" . . . -plugin
/usr/local/llvm11/bin/../lib/LLVMgold.so -plugin-opt=mcpu=ppc64 -plugin-opt=O3
. . .
LLVMgold.so is for the llvm linker to use. I had built
llvm10 with the gold option selected and there is:
# ls -ldT /usr/local/llvm11/bin/../lib/LLVMgold.so
-rwxr-xr-x 1 root wheel 94160 Jul 29 14:50:07 2020
/usr/local/llvm11/bin/../lib/LLVMgold.so
But, for the system clang 10 with -flto involved:
"/usr/bin/ld" . . . -plugin /usr/bin/../lib/LLVMgold.so -plugin-opt=mcpu=ppc64
-plugin-opt=O3 . . .
(yet there is no /usr/bin/../lib/LLVMgold.so present).
And for even the likes of just:
static volatile char big_area[67001] = "This is a test";
int main ()
{
big_area[67000] = '9';
}
commands like ( system clang and devel/llvm10 ):
cc -flto main.c
clang10 -flto main.c
for powerpc64 produce invalid a.out files that do
not even contain a main function when looked at
with the likes of objdump -d --prefix-addresses
and produce an a.out that does:
# ./a.out
Segmentation fault (core dumped)
Or when run inside gdb such builds produce things like:
Starting program: /root/c_tests/a.out
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x100412e8 in main ()
#1 0x10010718 in _start (argc=, argv=0xfbfffebb8,
env=, obj=, cleanup=,
ps_strings=)
at /usr/src/lib/csu/powerpc64/crt1_c.c:127
(gdb) disass
Dump of assembler code for function main:
=> 0x100412e8 <+0>: .long 0x0
0x100412ec <+4>: mullhwu r0,r1,r1
0x100412f0 <+8>: .long 0x0
0x100412f4 <+12>:vmsumshm v0,v2,v17,v19
0x100412f8 <+16>:.long 0x0
0x100412fc <+20>:.long 0x0
0x10041300 <+0>: .long 0xf
0x10041304 <+4>: stmwr31,-4128(r31)
0x10041308 <+0>: .long 0xf
0x1004130c <+4>: stmwr31,-5176(r31)
0x10041310 <+0>: .long 0x0
End of assembler dump.
For reference:
# uname -apKU
FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #13 r363590M: Sun Jul 26
20:14:08 PDT 2020
root@FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
powerpc powerpc64 1300102 1300102
# svnlite info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 543890
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 543890
Last Changed Date: 2020-07-31 22:52:17 -0700 (Fri, 31 Jul 2020)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) (LLVMgold.so and gnu's ld.gold)
On 2020-Jul-8, at 01:28, Stefan Eßer wrote: > Am 08.07.20 um 09:01 schrieb Mark Millard: >> The following is more informational than anything as far >> as I'm concerned. But there may be implications that I'm >> unaware of. (I sometimes experiment with toolchain use >> to see what the current status is for such use.) >> >> I attempted to build a system for 32-bit powerpc using clang >> and binutils, building head -r363000 ( from -r363000 ). (This >> was a cross build, amd64 -> powerpc.) It got a new type of >> failure, compared to my past experience: > > Hi Mark, > > thank you for the report. I have tested with "make universe" (with > default settings) that this version builds on all architectures, > but Ed Maste has already disabled -flto for powerpc64, due to run > time issues (floating point exception, IIRC). > > I know that you are actively working on PowerPC and I'd appreciate, > if you could provide me with information on which parameters cause > breakage and which work for you. The combination of CLANG with LTO > and GNU binutils cannot work - CLANG and GCC use incompatible file > formats to represent the intermediate object files. Hmm. It looks a little more complicated than that . . . Looks like the devel/llvm80 devel/llvm90 and devel/llvm10 options for powerpc64 include one for: GOLD=on: Build the LLVM Gold plugin for LTO That produces a plugin (LLVMgold.so) for use with gnu's ld.gold ( from devel/binutils ). The system-clang/llvm materials do not seem to include LLVMgold.so and so prevent use of that toolchain for LTO via devel/binutils . (A FreeBSD choice rather than a llvm* vs. binutils technically-blocking issue?) devel/binutils builds and installs /usr/local/bin/ld.gold for both 32-bit powerpc contexts and for powerpc64 contexts. However, for the 32-bit powerpc context, the devel/llvm* do not include an option to enable building LLVMgold.so . I do not know if this is just a ports choice vs. if this has a technically-blocking issue involved. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)
On 2020-Jul-8, at 20:35, Yuri Pankov wrote:
> Mark Millard wrote:
>> This seems to have broken doing buildworld buildkernel and
>> other things using make:
>> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
>> comparison operator should be either == or !=
>> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
>> comparison operator should be either == or !=
>> . . .
>> make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
>> operator should be either == or !=
>> . . .
>> make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
>> operator should be either == or !=
>> . . .
>> Using -d c shows the likes of:
>> . . .
>> lhs = "clang", rhs = "clang", op = ==
>> lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc",
>> op = ==
>> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
>> comparison operator should be either == or !=
>> lhs = "clang", rhs = "clang", op = ==
>> lhs = "LD", rhs = "LD", op = ==
>> . . .
>> left = 6.00, right = 2.00, op = <=
>> left = 6.00, right = 1.00, op = <=
>> lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs =
>> "clang", op = ==
>> make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
>> operator should be either == or !=
>> lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc",
>> op = ==
>> lhs = "clang", rhs = "gcc", op = ==
>> . . .
>> left = 0.00, right = 6.00, op = <=
>> left = 0.00, right = 3.00, op = <=
>> lhs = "clang", rhs = "gcc", op = ==
>> make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
>> operator should be either == or !=
>> lhs = "clang", rhs = "clang", op = ==
>> left = 11.00, right = 7.00, op = >=
>> lhs = "amd64", rhs = "arm", op = ==
>> (Now I just need to figure out how to get back to a working context.)
>
> For me, buildworld/buildkernel produced only warnings,
But, looking at the code in bmake, the expression is also
evaluated differently/incorrectly when it is classified as
having the problem of having a incorrect operator. In other
words: the behavior in make changes via misevaluated
expressions.
> though the one in ports is real issue:
>
> $ make config
> make: "/usr/ports/Mk/bsd.port.mk" line 2096: warning: String comparison
> operator should be either == or !=
> make: "/usr/ports/Mk/bsd.port.mk" line 2096: Malformed conditional
> (defined(MAKE_JOBS_NUMBER_LIMIT) && ( ${MAKE_JOBS_NUMBER_LIMIT} <
> ${_MAKE_JOBS_NUMBER} ))
> make: Fatal errors encountered -- cannot continue
> make: stopped in /usr/ports/devel/subversion
Not the only "real issue", I'm afraid.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)
This seems to have broken doing buildworld buildkernel and
other things using make:
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
operator should be either == or !=
. . .
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
operator should be either == or !=
. . .
Using -d c shows the likes of:
. . .
lhs = "clang", rhs = "clang", op = ==
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op
= ==
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
lhs = "LD", rhs = "LD", op = ==
. . .
left = 6.00, right = 2.00, op = <=
left = 6.00, right = 1.00, op = <=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "clang",
op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 100: warning: String comparison
operator should be either == or !=
lhs = "${${:UCOMPILER_TYPE}__${${:U${_empty_var_}}_cc_hash}}", rhs = "gcc", op
= ==
lhs = "clang", rhs = "gcc", op = ==
. . .
left = 0.00, right = 6.00, op = <=
left = 0.00, right = 3.00, op = <=
lhs = "clang", rhs = "gcc", op = ==
make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison
operator should be either == or !=
lhs = "clang", rhs = "clang", op = ==
left = 11.00, right = 7.00, op = >=
lhs = "amd64", rhs = "arm", op = ==
(Now I just need to figure out how to get back to a working context.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc)
On 2020-Jul-8, at 01:28, Stefan Eßer wrote: > Am 08.07.20 um 09:01 schrieb Mark Millard: >> The following is more informational than anything as far >> as I'm concerned. But there may be implications that I'm >> unaware of. (I sometimes experiment with toolchain use >> to see what the current status is for such use.) >> >> I attempted to build a system for 32-bit powerpc using clang >> and binutils, building head -r363000 ( from -r363000 ). (This >> was a cross build, amd64 -> powerpc.) It got a new type of >> failure, compared to my past experience: > > Hi Mark, > > thank you for the report. I have tested with "make universe" (with > default settings) that this version builds on all architectures, > but Ed Maste has already disabled -flto for powerpc64, due to run > time issues (floating point exception, IIRC). The builds I actually run are based on pure-llvm, not such odd mixes --nor even gcc+binutils. Also, I've not even tried a build since updating to head -r360311 --until now trying to update things to head -r363000 (or so). It is not obvious to me that FreeBSD intends for gcc based builds or binutils based buildworld buildkernel to be supported, even without mixing in LLVM. The ci.freebsd.org builds via gcc6 for amd64 have not completed in a very long time. My standard build procedure historically builds combinations like clang-with-binutils that used to completely build. (Not that the result worked to boot and operate an old PowerMac in recent times.) So I noticed this just by the build procedure failing. There are other combinations that failed some time ago that I turned off in my build procedure after sending a notice to the lists. As of the official switch to llvm-based for powerpc64 and powerpc, I've not been able to boot and operate anything but pure-llvm based builds, even for other types of builds that did "complete". That includes not being able to build and operate system based on modern gcc+binutils without LLVM. It appears to me that it would be a fair sized effort to get gcc+binutils working for powerpc64 or powerpc. My history with odd combinations derived from experimenting with more modern toolchains for powerpc64 and powerpc back in the gcc 4.2.1 days when no llvm based linker was affectively available. Although, I do like the idea of having code pass through and the result operate based on multiple toolchains, not just one, say, modern gcc+binutils as an alternate. Still, if FreeBSD declared "gcc not supported" and "binutils not supported" and "gcc+binutils not supported" for building FreeBSD, I'd just stick to llvm based. > I know that you are actively working on PowerPC and I'd appreciate, > if you could provide me with information on which parameters cause > breakage and which work for you. I think that the answer is: only pure llvm-based has worked for booting and operating since the switch away from gcc 4.2.1 for powerpc64 and powerpc. Everything else either stops the build early or does not operate correctly (as I remember anyway). Apparently, more combinations are landing in the "stops the build early" category over time. > The combination of CLANG with LTO > and GNU binutils cannot work - CLANG and GCC use incompatible file > formats to represent the intermediate object files. To my knowledge, a modern gcc+binutils does not work as the basis for a FreeBSD build for powerpc64 or powerpc. No need to have a mixed toolchain involved or -flto involved to have blocking issues. > This version of bc uses advanced algorithms (compared to the one > it replaced) for much reduced time complexity (a factor of more > than 100 for large numbers has been observed). It uses layering > for correctness, e.g. a set of "vector" management functions, that > are built as a separate compile unit. Compiling with -flto lets the > linker replace many function calls with constant parameters with > much more efficient inline instructions, resulting in 30% higher > performance. The code could be re-arranged to use inline functions > instead of relying on -flto, but this would be a lot of effort and > might make the code much harder to maintain. I'm not objecting to -flto use, even if it constrains what can be used as a basis for building and operating FreeBSD. There are issues that well predate -flto use that block other toolchains for powerpc64 and powerpc. If more than llvm-based is to be supported, I'd just suggest modern gcc+binutils, avoiding claiming support for mixes such as llvm+binutils. > If there is a condition that could be added to the Makefile to not > enable LTO if CLANG+binutils or GCC+LLD are mixed, then I'm willing > to add it. If it happened that -flto use vs. not needs to be configurable for other reasons and it happens to end up that turning it off allows the mixes, that would be fine. (But there could be more issues before any mixes would work.) This would not be the same as targeting being sure that some specific mix(es) would work (all issues handled for th
powerpc (32-bit): error: statement with no effect at sys/net/iflib.c:1258 : #define iflib_netmap_txq_init(ctx, txq) (0)
The following is more informational than anything as far as I'm concerned. But there may be implications that I'm unaware of. (I sometimes experiment with toolchain use to see what the current status is for such use.) In attempting to buildworld buildkernel via powerpc-unknown-freebsd13.0-gcc9 (via amd64->powerpc cross build): --- all_subdir_iflib --- /usr/src/sys/net/iflib.c:1258:41: error: statement with no effect [-Werror=unused-value] 1258 | #define iflib_netmap_txq_init(ctx, txq) (0) | ^ /usr/src/sys/net/iflib.c:2357:3: note: in expansion of macro 'iflib_netmap_txq_init' 2357 | iflib_netmap_txq_init(ctx, txq); | ^ . . . --- all_subdir_iflib --- *** [iflib.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/iflib .ERROR_TARGET='iflib.o' .ERROR_META_FILE='/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/iflib/iflib.o.meta' .MAKE.LEVEL='4' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='/usr/local/bin/powerpc-unknown-freebsd13.0-gcc9 --sysroot=/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp -B/usr/local/powerpc-unknown-freebsd13.0/bin/ -O2 -pipe -fno-common -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -g -fPIC -mlongcall -fno-omit-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/powerpc/include -I/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG -mno-altivec -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=address -Wno-error=aggressive-loop-optimizations -Wno-error=array-bounds -Wno-error=attributes -Wno-error=cast-qual -Wno-error=enum-compare -Wno-error=inline -Wno-error=maybe-uninitialized -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=overflow -Wno-error=sequence-point -Wno-error=shift-overflow -Wno-error=tautological-compare -Wno-unused-but-set-variable -Wno-error=stringop-overflow -Wno-error=memset-elt-size -Wno-error=packed-not-aligned -Wno-address-of-packed-member -Wno-format-zero-length -v -finline-limit=15000 -fms-extensions --param inline-unit-growth=100 --param large-function-growth=1000 -std=iso9899:1999 -c /usr/src/sys/net/iflib.c -o iflib.o; ctfconvert -L VERSION -g iflib.o;' .CURDIR='/usr/src/sys/modules/iflib' .MAKE='make' .OBJDIR='/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/iflib' .TARGETS='all' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='powerpc' MACHINE_ARCH='powerpc' MAKEOBJDIRPREFIX='/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/modules' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20200606' PATH='/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/sbin:/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/bin:/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/sbin:/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/bin:/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/bin:/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/modules/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.powerpc-xtoolchain-gcc.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/iflib/Makefile /usr/src/share/mk/bsd.kmod.mk /usr/src/share/mk/bsd.sysdir.mk /usr/src/sys/conf/kmod.mk /usr/src/sys/conf/kmod.opts.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/sys/modules/iflib/../Makefile.inc /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk /
powerpc64: error: 'tmp' is used uninitialized in 'atomic_cmpset_masked' stops buildkernel via gcc9
The following is more informational than anything as far
as I'm concerned. But there may be implications that I'm
unaware of. (I sometimes experiment with toolchain use
to see what the current status is for such use.)
In attempting to buildworld buildkernel via
powerpc64-unknown-freebsd13.0-gcc9 (via amd64->powerpc64
cross build):
--- vfs_vnops.o ---
In file included from /usr/src/sys/sys/systm.h:44,
from /usr/src/sys/kern/vfs_vnops.c:51:
/usr/src/sys/kern/vfs_vnops.c: In function 'atomic_cmpset_masked':
./machine/atomic.h:623:2: error: 'tmp' is used uninitialized in this function
[-Werror=uninitialized]
623 | __asm __volatile (
| ^
This was for:
#else
static __inline int
atomic_cmpset_masked(uint32_t *p, uint32_t cmpval, uint32_t newval,
uint32_t mask)
{
int ret;
uint32_ttmp;
__asm __volatile (
"1:\tlwarx %2, 0, %3\n\t" /* load old value */
"and %0, %2, %7\n\t"
"cmplw %4, %0\n\t" /* compare */
"bne- 2f\n\t" /* exit if not equal */
"andc %2, %2, %7\n\t"
"or %2, %2, %5\n\t"
"stwcx. %2, 0, %3\n\t" /* attempt to store */
"bne- 1b\n\t" /* spin if failed */
"li %0, 1\n\t" /* success - retval = 1 */
"b 3f\n\t" /* we've succeeded */
"2:\n\t"
"stwcx. %2, 0, %3\n\t" /* clear reservation (74xx) */
"li %0, 0\n\t" /* failure - retval = 0 */
"3:\n\t"
: "=&r" (ret), "=m" (*p), "+&r" (tmp)
: "r" (p), "r" (cmpval), "r" (newval), "m" (*p),
"r" (mask)
: "cr0", "memory");
return (ret);
}
(Looks like the lwarx initializes tmp to me.)
This was an attempt to cross-build head -r363000 ( via
-r363000 ).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc
The following is more informational than anything as far as I'm concerned. But there may be implications that I'm unaware of. (I sometimes experiment with toolchain use to see what the current status is for such use.) I attempted to build a system for 32-bit powerpc using clang and binutils, building head -r363000 ( from -r363000 ). (This was a cross build, amd64 -> powerpc.) It got a new type of failure, compared to my past experience: --- gh-bc.full --- /usr/local/powerpc-unknown-freebsd13.0/bin/ld: /usr/bin/../lib/LLVMgold.so: error loading plugin: Cannot open "/usr/bin/../lib/LLVMgold.so" cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [gh-bc.full] Error code 1 Yep: /usr/lib/LLVMgold.so when -B/usr/local/powerpc-unknown-freebsd13.0/bin/ was in use. I turns out that the link of gh-bc used -flto : make[4]: stopped in /usr/src/usr.bin/gh-bc .ERROR_TARGET='gh-bc.full' .ERROR_META_FILE='/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/usr.bin/gh-bc/gh-bc.full.meta' .MAKE.LEVEL='4' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='cc -target powerpc-unknown-freebsd13.0 --sysroot=/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp -B/usr/local/powerpc-unknown-freebsd13.0/bin/ -O2 -pipe -fno-common -B/usr/local/powerpc-unknown-freebsd13.0/bin/ -DMAINEXEC=bc -DNLSPATH=/usr/share/nls/%L/%N.cat -DBC_ENABLED -DBC_ENABLE_PROMPT -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_EXTRA_MATH -DBC_ENABLE_HISTORY -DBC_ENABLE_RAND -DDC_ENABLED -DNDEBUG -DVERSION=3.1.1 -I/usr/src/contrib/bc/include -DBC_ENABLE_NLS=1 -flto -g -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const- variable -Qunused-arguments -Wl,--secure-plt -o gh-bc.full args.o data.o file.o lang.o lex.o main.o num.o parse.o program.o read.o vector.o vm.o bc/bc.o bc/lex.o bc/parse.o dc/dc.o dc/lex.o dc/parse.o history/history.o bc_help.o dc_help.o lib.o lib2.o opt.o rand/rand.o ;' .CURDIR='/usr/src/usr.bin/gh-bc' .MAKE='make' .OBJDIR='/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/usr.bin/gh-bc' .TARGETS='all' DESTDIR='/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp' LD_LIBRARY_PATH='' MACHINE='powerpc' MACHINE_ARCH='powerpc' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20200606' PATH='/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/sbin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/bin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/sbin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/bin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/bin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.powerpc-clang_altbinutils-bootstrap.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/gh-bc/Makefile /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/usr.bin/gh-bc/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd. incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/usr.bin/gh-bc /usr/src/contrib/bc/src /usr/src/contrib/bc/gen /usr/src/contrib/bc/manuals /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/usr.bin/g
WITHOUT_BINUTILS= based head -r356427 FreeBSD context: x11-toolkits/qt5-gui build fails in poudriere: unable to execute command: Executable "as" doesn't exist!
[Ports was at -r528828 so this did not check -r531601 update to 5.14.2 of Qt5.] This is based on worlds built via WITHOUT_BINUTILS= . I was checking to see how things are for "[o]ne of the goals of this process [ExternalGCC] is to deprecate and remove the old GCC 4.2.1 and binutils 2.17.50 in the base system". On an aarch64 machine with head -r356427 that has a armv7 world directory tree for the same version that is set up for poudriere-devel use, I attempted to build ports but I ran into the following for the indirectly needed qt5-qui (I un-interlaced the output for easier reading): --- .obj/pixman-arm-neon-asm.o --- cc -c -O2 -pipe -mcpu=cortex-a7 -g -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -std=gnu11 -fvisibility=hidden -fno-exceptions -Wall -W -pthread -fPIC -DQT_ACCESSIBILITY - DQT_DBUS -DQT_FONTCONFIG -DQT_FREETYPE -DQT_GLIB -DQT_IMAGEFORMAT_PNG -DQT_OPENGL -DQT_SHAPE -DQT_XCB -DQT_XKB -DQT_XKBCOMMON -DQT_XRENDER -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWH ELPERS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT _DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -fno-integrated-as -I. -I../../include -I../../include/QtGui -I../../include/QtGui/5.13.2 -I../../include/QtGui/5.13.2/QtGui -I.tracegen -isystem /usr/local/include/libdrm -isystem /usr/local/include/qt5/QtCore/5.13.2 -isystem /usr/local/include/qt5/QtCore/5.13.2/QtCore -isystem /usr/loca l/include/qt5 -isystem /usr/local/include/qt5/QtCore -I.moc -isystem /usr/local/include/libpng16 -isystem /usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang ../3rdparty/pixman/pixman-arm-ne on-asm.S -o .obj/pixman-arm-neon-asm.o . . . --- .obj/pixman-arm-neon-asm.o --- cc: error: unable to execute command: Executable "as" doesn't exist! --- .obj/qdrawhelper_neon_asm.o --- cc -c -O2 -pipe -mcpu=cortex-a7 -g -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -std=gnu11 -fvisibility=hidden -fno-exceptions -Wall -W -pthread -fPIC -DQT_ACCESSIBILITY - DQT_DBUS -DQT_FONTCONFIG -DQT_FREETYPE -DQT_GLIB -DQT_IMAGEFORMAT_PNG -DQT_OPENGL -DQT_SHAPE -DQT_XCB -DQT_XKB -DQT_XKBCOMMON -DQT_XRENDER -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWH ELPERS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT _DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -fno-integrated-as -I. -I../../include -I../../include/QtGui -I../../include/QtGui/5.13.2 -I../../include/QtGui/5.13.2/QtGui -I.tracegen -isystem /usr/local/include/libdrm -isystem /usr/local/include/qt5/QtCore/5.13.2 -isystem /usr/local/include/qt5/QtCore/5.13.2/QtCore -isystem /usr/loca l/include/qt5 -isystem /usr/local/include/qt5/QtCore -I.moc -isystem /usr/local/include/libpng16 -isystem /usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang painting/qdrawhelper_neon_asm.S -o .obj/qdrawhelper_neon_asm.o . . . --- .obj/qdrawhelper_neon_asm.o --- cc: error: unable to execute command: Executable "as" doesn't exist! This suggests that a dependency on a ports binutils is needed and use of it is needed to keep this building when binutils 2.17.50 is absent in head. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r358966 on aarch64 fails to build base/gcc6: fatal error: bracket nesting level exceeded maximum of 256
On 2020-Mar-23, at 09:48, John Baldwin wrote:
> On 3/20/20 11:02 PM, Mark Millard wrote:
>> While trying to build base/gcc6 on aarch64 (implicitly targeting aarch64:
>> self hosted), it failed with:
>>
>> . . .
>> c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
>> deprecated [-Wdeprecated]
>> /wrkdirs/usr/ports/base/gcc6/work/gcc-6.5.0/gcc/config/aarch64/aarch64.md:817:10873:
>> fatal error: bracket nesting level exceeded maximum of 256
>> /wrkdirs/usr/ports/base/gcc6/work/gcc-6.5.0/gcc/config/aarch64/aarch64.md:817:10873:
>> note: use -fbracket-depth=N to increase maximum nesting level
>> 116 warnings and 1 error generated.
>> gmake[2]: *** [Makefile:1086: insn-attrtab.o] Error 1
>> gmake[2]: *** Waiting for unfinished jobs
>> . . .
>>
>> amd64 (implicitly targeting amd64: self hosted) did not have the problem.
>>
>> (These were just build-ability tests, no intent to install as stands.)
>>
>> base/binutils did not have such problems. (Actually installed on 32-bit
>> powerpc so more ports can build.)
>
> I think the devel/freebsd-gcc* ports have a workaround for this when being
> built
> on aarch64. We probably need the same fix for base/gcc when the build host is
> aarch64.
Looks like in devel/freebsd-gcc* such code is
like:
.if ${TARGETARCH} == "armv6" || ${TARGETARCH} == "aarch64"
. if ${COMPILER_TYPE} == clang
MAKE_ARGS+=CXXFLAGS=-fbracket-depth=512
. endif
.endif
There is no armv6 flavor in FLAVORS, nor armv7. But
having armv6 above but not armv7 looks a little odd.
(When I later tried base/gcc6 on an armv7 it also had
the problem.)
Also, TARGETARCH seems to be the target, not the
host. All hosts using clang get the larger
bracket depth for handling the listed arm targets,
if I read the above right.
base/gcc6 does not use FLAVOR and has:
TARGETARCH= ${ARCH:S/amd64/x86_64/}
So, again, it looks like explicitly covering "armv7"
would be appropriate for base/gcc* examples that
can handle armv7 reasonably. (Unsure for gcc6.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r358966 on aarch64 fails to build base/gcc6: fatal error: bracket nesting level exceeded maximum of 256
While trying to build base/gcc6 on aarch64 (implicitly targeting aarch64: self hosted), it failed with: . . . c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated] /wrkdirs/usr/ports/base/gcc6/work/gcc-6.5.0/gcc/config/aarch64/aarch64.md:817:10873: fatal error: bracket nesting level exceeded maximum of 256 /wrkdirs/usr/ports/base/gcc6/work/gcc-6.5.0/gcc/config/aarch64/aarch64.md:817:10873: note: use -fbracket-depth=N to increase maximum nesting level 116 warnings and 1 error generated. gmake[2]: *** [Makefile:1086: insn-attrtab.o] Error 1 gmake[2]: *** Waiting for unfinished jobs . . . amd64 (implicitly targeting amd64: self hosted) did not have the problem. (These were just build-ability tests, no intent to install as stands.) base/binutils did not have such problems. (Actually installed on 32-bit powerpc so more ports can build.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r358966 attempting system lldb build, targeting powerpc64: still gets undefined symbol: lldb_private::formatters::CMTimeSummaryProvider ...
For reference: --- lldb.full --- ld: error: undefined symbol: lldb_private::formatters::CMTimeSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&) >>> referenced by ObjCLanguage.cpp >>> ObjCLanguage.o:(.toc+0x18) in archive >>> /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/liblldb/liblldb.a c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [lldb.full] Error code 1 The above is not new but having system llvm10 materials has not changed the status. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
A small llvm/clang patch for powerpc that Roman Divacky provided back in 2017-May: keep or revert?
I've tracked applying Roman Divacky's patch below for powerpc for nearly 3 years. (I had to follow some restructuring and the below is from a base of head -r358510 .) The patch never made it into a llvm/clang update that I've seen. # svnlite diff /usr/src/contrib/llvm-project/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp Index: /usr/src/contrib/llvm-project/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp === --- /usr/src/contrib/llvm-project/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp (revision 358966) +++ /usr/src/contrib/llvm-project/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp (working copy) @@ -1326,7 +1326,7 @@ // For SVR4, don't emit a move for the CR spill slot if we haven't // spilled CRs. if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4) - && !MustSaveCR) + && (!MustSaveCR && isPPC64)) continue; // For 64-bit SVR4 when we have spilled CRs, the spill location So !isPPC64 would not "continue" but instead flow to the following code for dealing with spills of CRs for 32-bit powerpc. Roman wrote at the time: "I believe this should make llvm emit the cfi instructions for the unwind case you mentioned in the llvm PRs." Is this still relevant for the modern head and later FreeBSD context? Is it still appropriate for llvm (even if it is not needed for head)? If it is not relevant to head, then I could revert the patch in my environment. If it is relevant to llvm, I'd probably try to contact Roman to remind him of the patch in case he would want it in llvm. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
powerpc64 clang 9 ABI vs. gcc ABI and clang V10 and FreeBSD 13: -msvr4-struct-return by default for clang in order to match gcc/g++?
There is a review on llvm.org for having clang match the gcc/g++ ABI used for powerpc64 FreeBSD for what is now a known mismatch (at least for clang 9 as it is for ELFv2): https://reviews.llvm.org/D73290 In essence, clang 9 is using -maix-struct-return (stack space and a pointer to it) which does not match what gcc/g++ is using (registers holding the content). The register that hold the pointer in one leads to problems for the mix when used as an address with values that are not addresses. Historically FreeBSD used -msvr4-struct-return style, matching gcc/g++. Using -maix-struct-return style is new. With https://svnweb.freebsd.org/base/projects/clang1000-import/ and https://svnweb.freebsd.org/ports/head/devel/llvm10/ active, it might be appropriate to to have the change adopted and be part of 13's definition. This would, of course, lead to another incompatible powerpc64 ABI change before 13 freezes. I originally ran into this using C++'s steady-clock's now return values, leading to program crashes from the mismatched ABI's when I had g++ using the FreeBSD system headers and libraries instead of the gcc ones (so libc++ was in use, for example). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present [the added "static" caused the failures]
[Turns out to be the added "static".]
On 2020-Feb-2, at 15:10, Mark Millard wrote:
> [I forgot to send some context.]
>
> On 2020-Feb-2, at 14:51, Mark Millard wrote:
>
>> --- kernel.full ---
>> ld: error: undefined symbol: dflt_font_8
> referenced by ofw_syscons.c
> ofw_syscons.o:(.toc+0x10)
>> ld: error: undefined symbol: dflt_font_14
> referenced by ofw_syscons.c
> ofw_syscons.o:(.toc+0x18)
>> ld: error: undefined symbol: dflt_font_16
> referenced by ofw_syscons.c
> ofw_syscons.o:(.toc+0x20)
>>
>> This is from loss of:
>>
>>
>>
>> font.h optionalsc \
>>
>>compile-with"uudecode <
>> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
>> dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode <
>> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
>> dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode
>> < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
>> dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
>>no-obj no-implicit-rule before-depend \
>>
>>clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
>> ${SC_DFLT_FONT}-8x8"
>>
>>
>> in /head/sys/conf/files.powerpc .
>>
>>
>> FYI for why I have sc present:
>>
>> Historically, I've had two PowerMac contexts, one of which
>> worked with sc but not vt and another of which worked with
>> vt but not sc.
>>
>> I build with both sc and vt present and change which is
>> used as I move the media between machines.
>
> FYI: my powerpc* kernel config files have (using a powerpc64
> example):
>
> include "GENERIC64"
>
> . . .
>
> nooptions PS3 # Sony Playstation 3
> HACK!!! to allow sc
>
> . . .
>
> # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt
> historically mishandled during booting
> device sc
> #device kbdmux # HACK: already listed by vt
> options SC_OFWFB# OFW frame buffer
> options SC_DFLT_FONT# compile font in
> makeoptions SC_DFLT_FONT=cp437
>
>
> I'm exploring rebuilding from scratch, but it
> may be that this change could use some form
> of UPDATING note about how to deal with the
> changes.
The following enabled my powerpc* builds: I dropped
"static " from each declaration that is generated.
(In this form some whitespace might not be
preserved below.)
# svnlite diff /usr/src/sys/conf/files
Index: /usr/src/sys/conf/files
===
--- /usr/src/sys/conf/files (revision 357419)
+++ /usr/src/sys/conf/files (working copy)
@@ -35,7 +35,7 @@
no-obj no-implicit-rule before-depend \
clean "feeder_rate_gen.h"
font.h optionalsc_dflt_font\
- compile-with"uudecode <
${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'static u_char
dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode <
${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'static u_char
dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode <
${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'static u_char
dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h"
\
+ compile-with"uudecode <
${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode <
${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode <
${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h"
\
no-obj no-implicit-rule before-depend \
clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
${SC_DFLT_FONT}-8x8"
snd_fxdiv_gen.hoptional sound
\
If the "static"s are strongly wanted, then the powerpc*
families need to be reworked to allow for such.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present
[I forgot to send some context.]
On 2020-Feb-2, at 14:51, Mark Millard wrote:
> --- kernel.full ---
> ld: error: undefined symbol: dflt_font_8
referenced by ofw_syscons.c
ofw_syscons.o:(.toc+0x10)
> ld: error: undefined symbol: dflt_font_14
referenced by ofw_syscons.c
ofw_syscons.o:(.toc+0x18)
> ld: error: undefined symbol: dflt_font_16
referenced by ofw_syscons.c
ofw_syscons.o:(.toc+0x20)
>
> This is from loss of:
>
>
>
> font.h optionalsc \
>
> compile-with"uudecode <
> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
> dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode <
> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
> dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode <
> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
> dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
> no-obj no-implicit-rule before-depend \
>
> clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
> ${SC_DFLT_FONT}-8x8"
>
>
> in /head/sys/conf/files.powerpc .
>
>
> FYI for why I have sc present:
>
> Historically, I've had two PowerMac contexts, one of which
> worked with sc but not vt and another of which worked with
> vt but not sc.
>
> I build with both sc and vt present and change which is
> used as I move the media between machines.
FYI: my powerpc* kernel config files have (using a powerpc64
example):
include "GENERIC64"
. . .
nooptions PS3 # Sony Playstation 3
HACK!!! to allow sc
. . .
# HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt
historically mishandled during booting
device sc
#device kbdmux # HACK: already listed by vt
options SC_OFWFB# OFW frame buffer
options SC_DFLT_FONT# compile font in
makeoptions SC_DFLT_FONT=cp437
I'm exploring rebuilding from scratch, but it
may be that this change could use some form
of UPDATING note about how to deal with the
changes.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r357401 broke my powerpc/powerpc64 builds: I build with sc present
--- kernel.full ---
ld: error: undefined symbol: dflt_font_8
>>> referenced by ofw_syscons.c
>>> ofw_syscons.o:(.toc+0x10)
ld: error: undefined symbol: dflt_font_14
>>> referenced by ofw_syscons.c
>>> ofw_syscons.o:(.toc+0x18)
ld: error: undefined symbol: dflt_font_16
>>> referenced by ofw_syscons.c
>>> ofw_syscons.o:(.toc+0x20)
This is from loss of:
font.h optionalsc \
compile-with"uudecode <
/usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode <
/usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode <
/usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
no-obj no-implicit-rule before-depend \
clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
${SC_DFLT_FONT}-8x8"
in /head/sys/conf/files.powerpc .
FYI for why I have sc present:
Historically, I've had two PowerMac contexts, one of which
worked with sc but not vt and another of which worked with
vt but not sc.
I build with both sc and vt present and change which is
used as I move the media between machines.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r356426 32-bit powerpc : clang vs gcc9 C-ABI: *not* the same: clang is doing -maix-struct-return style
system-clang (C) handles returning example struct based on it
being on the stack (-maix-struct-return style); gcc9 via
registers r3 and r4 (-msvr4-struct-return style). So this
somewhat tracks what was observed for the C++ ABI.
The evidence from on a old G4 PowerMac3,6 . . .
The source code:
# more just_struct.c
struct two {
int a,b;
};
struct two f(void) {
struct two r= { 0, 1};
return r;
}
# cc -std=c99 -pedantic -g -O2 -c just_struct.c
# objdump -d --prefix-addresses just_struct.o | more
just_struct.o: file format elf32-powerpc-freebsd
Disassembly of section .text:
li r4,1
0004 stw r4,4(r3)
0008 li r4,0
000c stw r4,0(r3)
0010 blr
So it expect r3 to point to the space the caller
provided, probably via stack space.
This appears to be -maix-struct-return style.
# /usr/local/bin/powerpc-unknown-freebsd13.0-gcc9 -std=c99 -pedantic -g -O2 -c
just_struct.c
# objdump -d --prefix-addresses just_struct.o | more
just_struct.o: file format elf32-powerpc-freebsd
Disassembly of section .text:
li r3,0
0004 li r4,1
0008 blr
So it returned via register r3 and r4.
This appears to be -msvr4-struct-return style.
# gcc9 -std=c99 -pedantic -g -O2 -c just_struct.c
# objdump -d --prefix-addresses just_struct.o | more
just_struct.o: file format elf32-powerpc-freebsd
Disassembly of section .text:
li r3,0
0004 li r4,1
0008 blr
So it returned via register r3 and r4.
This appears to be -msvr4-struct-return style.
So is clang using the aix ABI the right ABI?
Or does GCC need to change?
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r356426 for 32-bit powerpc vs. powerpc-unknown-freebsd13.0-g++9 and g++9: not (fully) clang++-ABI compatible (using system-headers and libraries, not gcc's)
[So far I have not checked if there is a
somewhat analogous C (not C++) issue or
not for gcc9 . For C++, when registers are
used vs. when stack space is used does not
always match system-clang++ for g++9
targeting 32-bit powerpc.]
Building on a head -r356426 32-bit powerpc
the following program:
# more just_now.cpp
#include
#include
int main(void)
{
auto now0{std::chrono::steady_clock::now()};
auto now1{std::chrono::steady_clock::now()};
volatile std::vector ta{ {now0,now1} };
return 0;
}
via:
# g++9 -std=c++17 -nostdinc++ -I/usr/include/c++/v1 \
-pedantic -g -O2 -nodefaultlibs -lc++ -lc -lgcc_s \
just_now.cpp
produces an a.out that SIGSEGV's. Note: lack of -O?
still fails, the code is just shorter for my presentation
purposes when I use something like -O2 .
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x41861000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4193d000)
libc.so.7 => /lib/libc.so.7 (0x41969000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b74000)
The same is true for powerpc-unknown-freebsd13.0-g++9 ,
including when used via just:
# /usr/local/bin/powerpc-unknown-freebsd13.0-g++9 \
-std=c++17 -pedantic -g -O2 just_now.cpp
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x41861000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4193d000)
libm.so.5 => /lib/libm.so.5 (0x41969000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x419a4000)
libc.so.7 => /lib/libc.so.7 (0x419cc000)
( The two g++9 variants use /usr/local/bin/ld vs.
/usr/local/bin/powerpc-unknown-freebsd13.0-ld . )
Here is the beginning of main's code from the g++9
variants:
Dump of assembler code for function main():
0x01800530 <+0>: stwur1,-48(r1)
0x01800534 <+4>: mflrr0
0x01800538 <+8>: stw r0,52(r1)
0x0180053c <+12>:stw r30,40(r1)
0x01800540 <+16>:stw r31,44(r1)
0x01800544 <+20>:bl 0x1810d3c
<_znst3__16chrono12steady_clock3no...@got.plt>
0x01800548 <+24>:mr r30,r3
0x0180054c <+28>:mr r31,r4
0x01800550 <+32>:bl 0x1810d3c
<_znst3__16chrono12steady_clock3no...@got.plt>
. . .
Note the last 2 mr instructions: the code is expecting
now()'s time_point to be returned in registers, not
in stack space provided by main. It is not expecting
now() to require an address for the time_point (in r3).
(That does not match the system-libraries
implementation: that code will try to use r3
as pointing to where to put the time_point.)
By contrast, via system clang:
# c++ -std=c++17 -nostdinc++ -I/usr/include/c++/v1 \
-pedantic -g -O2 -nodefaultlibs -lc++ -lc -lgcc_s \
just_now.cpp
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x41861000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4193d000)
libc.so.7 => /lib/libc.so.7 (0x41969000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b74000)
Dump of assembler code for function main():
0x01800768 <+0>: mflrr0
0x0180076c <+4>: stw r0,4(r1)
0x01800770 <+8>: stwur1,-32(r1)
0x01800774 <+12>:addir3,r1,24
0x01800778 <+16>:bl 0x1810aa0
<_znst3__16chrono12steady_clock3no...@got.plt>
0x0180077c <+20>:addir3,r1,16
0x01800780 <+24>:bl 0x1810aa0
<_znst3__16chrono12steady_clock3no...@got.plt>
. . .
clang++ creates stack space and passes the address
of that stack space, with distinct values for
each call. It does not expect to get the
time_point from a now() from registers after the
calls.
(That does match the system-libraries
implementation: that code will try to use r3
as pointing to where to put the time_point.)
This may mean that building gcc9 without
the full bootstrap vs. with the full
bootstrap would have consequences for the
gcc library code and if it matched the
FreeBSD system or not: when built by
clang++ the code would have clang++'s
code generation ABI properties.
But even without a full bootstrap, use
of g++9 variants (as they are) may be
problematical for building ports and
other code.
For reference:
# g++9 -v
Using built-in specs.
COLLECT_GCC=g++9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc9/gcc/powerpc-portbld-freebsd13.0/9.2.0/lto-wrapper
Target: powerpc-portbld-freebsd13.0
Configured with: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.2.0/configure
--disable-multilib --disable-plugin --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9
--libexecdir=/usr/local/libexec/gcc9 --program-suffix=9
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc9/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc9 --build=powerpc-portbld-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)
# powerpc-unknown-f
The 32-bit powerpc FreeBSD early-boot "tfo_ccache_bucket panic" on (2 socket?) G5s: visible at -r356118, not happening at -r356109
This is based on testing artifact.ci.freebsd.org 32-bit powerpc materials on some (2 socket) G5s. It is the later FreeBSD head revision that causes an earlier boot-failure than the other one that I recently reported. There are no 32-bit powerpc artifacts between -r356109 and -r356118 (non-inclusive of either end). This limits how specific the evidence is -- but also avoids getting my personal builds involved as a potential problem source. I'll note that -r356111 was for: Use LLVM as default toolchain for all PowerPC targets and -r356014 was for: [PowerPC] enable atomic.c in compiler_rt and do not check and forces lock/lock_free decisions in compiled time (and would start to be put to use by -r356111 and later). This suggests the possibility of atomic-activity that is insufficient on the example G5 machines. (I only have access to dual socket G5s.) But I've no specific evidence about the llvm generated code leads to the tfo_ccache_bucket panic. The crashes look like (typed from a screen shot): . . . Timecounters tick every 1.000 msec firewire0: w nodes, maxhop <= 1 cable IRM irm(1) (me) firewire0: bus manager 1 . . . (1 or 2 lines that only sometimes show up, then) . . . panic: lock "tfo_ccache_bucket" 0xd2858008 already initialized cpuid = 0 time = 1 KDB: stack backtrace 0xd00048b0: at kdb_backtrace+0x64 0xd0004910: at vpanic+0x200 0xd0004980: at panic+0x64 0xd00049c0: at lock_init+0x200 0xd00049d0: at _mtx_init+0x7c 0xd00049f0: at tcp_fastopen_init+0x1e8 0xd0004a20: at tcp_init+0x234 0xd0004a50: at protosv_init+0x1d4 0xd0004a60: at vnet_domain_init+0x5c 0xd0004a80: at vnet_register_sysinit+0x154 0xd0004ab0: at mi_startup+0x280 0xd0004af0: at btext+0x74 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x74: addi r3,r0,0x0 db> === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r356289 - head
John Baldwin jhb at FreeBSD.org wrote on Thu Jan 2 21:41:07 UTC 2020 : > On 1/2/20 1:34 PM, John Baldwin wrote: > > Author: jhb > > Date: Thu Jan 2 21:34:44 2020 > > New Revision: 356289 > > URL: https://svnweb.freebsd.org/changeset/base/356289 > > > > Log: > > Look for cross toolchain makefiles in /usr/share/toolchains. > > > > The freebsd-binutils and freebsd-gcc* packages install toolchain > > makefiles to /usr/share/toolchains rather than LOCALBASE. > > The short version is that you can do something like this to use GCC > as the system compiler (/usr/bin/cc): > > cd /usr/ports/base/binutils ; make install clean > cd ../gcc6 ; make install clean > > Then 'make CROSS_TOOLCHAIN=freebsd-gcc6 buildworld', etc. If you aren't > planning on doing cross-builds you can set CROSS_TOOLCHAIN in /etc/src.conf. > > As described elsewhere, the base/* packages can be cross-built (along > with pkg), so for any architectures not yet using clang we could fairly > easily provide a cross-built package repo (though that architecture list > is becoming rather small). I will probably add a base/gcc9 port once we > can build a full system with gcc9. Just an FYI from some experiments that I did recently: devel/binutils@powerpc and devel/binutils@powerpc64 and base/binutils@powerpc and base_binutils@powerpc64 do not put out the same content as lld or the old toolchain's ld (still used normally for 32-bit powerpc). buildkernel runs to completion but the result crashes from the kernel sseflf-loading and what was produced not matching. For example, binutils put out very few ABS symbols compared to lld/old-ld and classifies the kernel as ET_EXEC, not ET_DYN, because of the non-zero VirtAddr in: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align . . . LOAD 0x00 0x0010 0x0010 0xd9786c 0x1083648 RWE 0x1 . . . (I'm not claiming that is all there is that matters.) These points are true using system-clang as the compiler. (I've only cross-built so far.) I do not know if other architectures have similar issues or not. But, it appears that in some cases, there is more work to allowing the GNU linker to be used, for at least buildkernel . I do not know if there is an intent to support a (modern) GNU binutils ld (in addition to lld) or not. So it may be that the effort would not be put in. (I'm not claiming which side(s) would change if the effort was put in.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 32-bit powerpc kernel builds (head -r356187): old ld (works) vs. devel/binutils@powerpc based (fails to boot): DYNAMIC vs. EXEC_P (powerpc64 lld too)
On 2019-Dec-31, at 16:44, Mark Millard wrote: > On 2019-Dec-31, at 14:52, Mark Millard wrote: > >> My attempt to buildkernel via devel/binutils@powerpc >> produces a kernel that gets a very early crash. >> >> Looking at the normal and alternate kernels a little >> shows. . . >> >> >> >> Old ld (and such): >> >> /boot/kernel/kernel: file format elf32-powerpc-freebsd >> /boot/kernel/kernel >> architecture: powerpc:common, flags 0x0150: >> HAS_SYMS, DYNAMIC, D_PAGED >> start address 0x001001e0 >> . . . >> 00e7a034 l O *ABS* .hidden _DYNAMIC >> >> Produced via (from kernel.full.meta): >> >> CMD @ld -m elf32ppc_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc >> --secure-plt -pie --no-warn-mismatch --warn-common --export-dynamic >> --dynamic-linker /red/herring -X -o kernel.full locore.o . . . >> >> >> devel/binutils@powerpc based: >> >> /boot/kerbad/kernel: file format elf32-powerpc-freebsd >> /boot/kerbad/kernel >> architecture: powerpc:common, flags 0x0112: >> EXEC_P, HAS_SYMS, D_PAGED >> start address 0x00100200 >> >> 00e7a034 l O .dynamic _DYNAMIC >> >> Produced via (from kernel.full.meta): >> >> CMD @/usr/local/powerpc-unknown-freebsd13.0/bin/ld -m elf32ppc_fbsd >> -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc --secure-plt --build-id=sha1 >> -pie --no-warn-mismatch --warn-common --export-dynamic >> --dynamic-linker /red/herring -X -o kernel.full locore.o . . . > I see the same sort of thing for powerpc64 kernels, based on system lld and such vs. based on devel/binutils@powerpc64 . (The old 2 socket/2-cores-per PowerMac is rebuilding the 435 ports on head -r356187 .) > _GLOBAL_OFFSET_TABLE_ has a similar status. > > In fact, there is a big difference in the two > context's ABS lists: devel/binutils@powerpc > produces a very short list: > > # readelf -a /boot/kerbad/kernel | grep "\" | more > 2: 0070 0 NOTYPE GLOBAL DEFAULT ABS dlmisssize > 569: 00100100 0 NOTYPE GLOBAL DEFAULT ABS kernbase > 5103: 0020 0 NOTYPE GLOBAL DEFAULT ABS testppc64size > 8156: 0018 0 NOTYPE GLOBAL DEFAULT ABS restorebridgesize > 9078: 00b0 0 NOTYPE GLOBAL DEFAULT ABS imisssize > 12351: 00f0 0 NOTYPE GLOBAL DEFAULT ABS dsmisssize > 25923: 0070 0 NOTYPE GLOBAL DEFAULT ABS dlmisssize > 26490: 00100100 0 NOTYPE GLOBAL DEFAULT ABS kernbase > 31024: 0020 0 NOTYPE GLOBAL DEFAULT ABS testppc64size > 34077: 0018 0 NOTYPE GLOBAL DEFAULT ABS restorebridgesize > 34999: 00b0 0 NOTYPE GLOBAL DEFAULT ABS imisssize > 38272: 00f0 0 NOTYPE GLOBAL DEFAULT ABS dsmisssize > > but the old ld produces a much longer list: > > # readelf -a /boot/kernel/kernel | grep "\" | more > 2: 0070 0 NOTYPE GLOBAL DEFAULT ABS dlmisssize > 212: 00e793dc 0 NOTYPE GLOBAL DEFAULT ABS __start_set_gfb_set > 462: 00e793c8 0 NOTYPE GLOBAL DEFAULT ABS __start_set_mmu_set > 569: 00100100 0 NOTYPE GLOBAL DEFAULT ABS kernbase > 1334: 00dd5728 0 NOTYPE GLOBAL DEFAULT ABS > __start_set_sdt_probes_set > 1395: 00e5e608 0 NOTYPE GLOBAL DEFAULT ABS __start_set_vnet > 1765: 01183648 0 NOTYPE GLOBAL DEFAULT ABS end > 1798: 00dd36d0 0 NOTYPE GLOBAL DEFAULT ABS > __stop_set_sysinit_set > 1857: 00dd4e34 0 NOTYPE GLOBAL DEFAULT ABS > __stop_set_modmetadata_set . . . (detail dropped) . . . > 35963: 00dd5674 0 NOTYPE GLOBAL DEFAULT ABS > __stop_set_kbddriver_set > 35987: 00dd5728 0 NOTYPE GLOBAL DEFAULT ABS > __stop_set_sdt_providers_set > 36015: 01183648 0 NOTYPE GLOBAL DEFAULT ABS _end > 36625: 00e793d4 0 NOTYPE GLOBAL DEFAULT ABS > __start_set_videodriver_set > 36828: 00dd7954 0 NOTYPE GLOBAL DEFAULT ABS > __start_set_scterm_set > 37429: 00e9786c 0 NOTYPE GLOBAL DEFAULT ABS _edata > 37854: 00dd7988 0 NOTYPE GLOBAL DEFAULT ABS > __start_set_vt_drv_set > 38049: 00dc2240 0 NOTYPE GLOBAL DEFAULT ABS > __stop_set_sysctl_set > 38270: 00f0 0 NOTYPE GLOBAL DEFAULT ABS dsmisssize > > So what do the __start_set_* and __stop_set_* symbols > show up as in /boot/kerbad/kernel generally? PROTECTED > visibility as a GLOBAL as it turns out: > > # readelf -a /boot/kerbad/kernel | egrep "__(start|stop)_set_" | more > 00e83680 002c0701 R_PPC_ADDR32 __stop_set_uart_fdt_class_set > + 0 > 00e83684 0021a801 R_PPC_ADDR32 __start_set_uart_fdt_class_set > + 0 > 212: 00e793dc 0 NOTYPE GLOBAL PROTECTED 48 __start_set_gfb_set > 462: 00e793c8 0 NOTYPE GLOBAL PROTECTED 45 __start_set_mmu_set . . . (detail dropped) . . . > 35681: 00dd565c 0 NOTYPE GLOBAL PROTECT
For reliable builds, gnu/usr.bin/binutils/Makefile needs similar to gnu/usr.bin/binutils/Makefile.inc0 TARGET_CPUARCH use, not ${TARGET} use
My cross-build attempts were failing to build
ld.bfd for use for building LIB32 for powerpc64
until I made the following change:
# svnlite diff gnu/usr.bin/binutils/Makefile
Index: gnu/usr.bin/binutils/Makefile
===
--- gnu/usr.bin/binutils/Makefile (revision 356187)
+++ gnu/usr.bin/binutils/Makefile (working copy)
@@ -15,7 +15,16 @@
# GNU binutils 2.17.50 ld.
# Except if we are on powerpc, that needs the ld from binutils to link
# 32-bit binaries.
-.if ${MK_LLD_IS_LD} == "no" || ${TARGET} == "powerpc"
+#
+# Localized variation of some gnu/usr.bin/binutils/Makefile.inc0
+# content:
+.if defined(TARGET_ARCH)
+HACK_TARGET_CPUARCH=${TARGET_ARCH:${__TO_CPUARCH}}
+.else
+HACK_TARGET_CPUARCH=${MACHINE_CPUARCH}
+.endif
+#
+.if ${MK_LLD_IS_LD} == "no" || ${HACK_TARGET_CPUARCH} == "powerpc"
SUBDIR.${MK_BINUTILS}+=ld
.endif
Otherwise, gnu/usr.bin/binutils/ld/Makefile was not used
to build ld.bfd and the build ending up stopping, reporting
the lack of anything at the path it specified to clang for
executing the 32-bit linker.
(No place else under gnu/ was using ${TARGET} . Many
places were using ${MACHINE_CPUARCH} . But straight use
of ${MACHINE_CPUARCH} here did not work for the context.
Thus, I went for the more general code from Makefile.inc0
instead, reusing what others had already figured out.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: A devel/freebsd-gcc*/Makefile suggestion to avoid base/binutil preventing freebsd-gcc* builds
On 2019-Dec-31, at 16:37, John Baldwin wrote:
> On 12/26/19 7:54 PM, Mark Millard wrote:
>> Context: devel/freebsd-gcc* (for example)
>> using:
>>
>>--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
>>--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
>>
>> The likes of ${BU_PREFIX}-ld possibly also
>> exists someplace else on the path in use.
>> So I suggest that the BUILD_DEPENDS and
>> RUN_DEPENDS cause the full path to be
>> checked so that the full path will be
>> created if they do not exist already.
>> So, using devel/freebsd-gcc9 as an example,
>> . . .
>>
>>
>> # svnlite diff /usr/ports/devel/freebsd-gcc9/
>> Index: /usr/ports/devel/freebsd-gcc9/Makefile
>> ===
>> --- /usr/ports/devel/freebsd-gcc9/Makefile (revision 520539)
>> +++ /usr/ports/devel/freebsd-gcc9/Makefile (working copy)
>> @@ -16,8 +16,8 @@
>> LIB_DEPENDS= libgmp.so:math/gmp \
>> libmpfr.so:math/mpfr \
>> libmpc.so:math/mpc
>> -BUILD_DEPENDS= ${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
>> -RUN_DEPENDS=${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
>> +BUILD_DEPENDS=
>> ${LOCALBASE}/bin/${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
>> +RUN_DEPENDS=
>> ${LOCALBASE}/bin/${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
>>
>> FLAVORS= aarch64 amd64 i386 mips mips64 powerpc powerpc64 riscv64 sparc64
>> TARGETARCH= ${FLAVOR}
>>
>> This avoids later not finding the file via
>> the full path in such contexts.
>
> I don't see why this would ever be the case that we'd have, say,
> x86_64-unknown-freebsd13.0-ld anywhere but in LOCALBASE from the
> amd64-binutils package.
>
> base/binutils only installs /usr/bin/ld and /usr/${BUTARGET}/bin/ld.
> It doesn't install a BUTARGET-ld binary anywhere. I might end up
> axeing /usr/BUTARGET/bin from the base/binutils package. I've
> trimmed most of the similar type files from base/gcc6 recently.
Good to know. Thanks.
(My use goes back to when base/binutils did put in place
the likes of /usr/bin/BUTARGET-ld --as reported in a
bugzilla comment back in 2018-Feb. So I'd seen the
problem in the past and had to work around it.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang
On 2019-Dec-31, at 16:41, John Baldwin wrote: > On 12/26/19 11:39 PM, Mark Millard wrote: is missing the patch-clang-vec_step that is in: FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ >>> >>> That is a hack that can be used to work around the issue; I strongly >>> recommend addressing this in clang properly, though. > > I think using the hack patch in devel/freebsd-gcc* is fine for now, but can > you confirm if both 6 and 9 need it or only 9? > devel/freebsd-gcc6 and devel/freebsd-gcc9 both need it. The vec_step identifier has been in use in gcc's gcc/tree-vect-loop.c for a long time and still is in use. Going the other way, reserving vec_step for opencl/altivec for PowerPc's has been in clang for a long time. I've had to have local patches for lang/gcc6 and later and in devel/powerpc64-gcc historically (2017+) because of my clang-targeting-PowerPc activities and trying to build gcc versions via clang as part of those activities. (Of course, some places have patches of their own now.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 32-bit powerpc kernel builds (head -r356187): old ld (works) vs. devel/binutils@powerpc based (fails to boot): DYNAMIC vs. EXEC_P
On 2019-Dec-31, at 14:52, Mark Millard wrote: > My attempt to buildkernel via devel/binutils@powerpc > produces a kernel that gets a very early crash. > > Looking at the normal and alternate kernels a little > shows. . . > > > > Old ld (and such): > > /boot/kernel/kernel: file format elf32-powerpc-freebsd > /boot/kernel/kernel > architecture: powerpc:common, flags 0x0150: > HAS_SYMS, DYNAMIC, D_PAGED > start address 0x001001e0 > . . . > 00e7a034 l O *ABS* .hidden _DYNAMIC > > Produced via (from kernel.full.meta): > > CMD @ld -m elf32ppc_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc > --secure-plt -pie --no-warn-mismatch --warn-common --export-dynamic > --dynamic-linker /red/herring -X -o kernel.full locore.o . . . > > > devel/binutils@powerpc based: > > /boot/kerbad/kernel: file format elf32-powerpc-freebsd > /boot/kerbad/kernel > architecture: powerpc:common, flags 0x0112: > EXEC_P, HAS_SYMS, D_PAGED > start address 0x00100200 > > 00e7a034 l O .dynamic _DYNAMIC > > Produced via (from kernel.full.meta): > > CMD @/usr/local/powerpc-unknown-freebsd13.0/bin/ld -m elf32ppc_fbsd -Bdynamic > -T /usr/src/sys/conf/ldscript.powerpc --secure-plt --build-id=sha1 -pie > --no-warn-mismatch --warn-common --export-dynamic > --dynamic-linker /red/herring -X -o kernel.full locore.o . . . _GLOBAL_OFFSET_TABLE_ has a similar status. In fact, there is a big difference in the two context's ABS lists: devel/binutils@powerpc produces a very short list: # readelf -a /boot/kerbad/kernel | grep "\" | more 2: 0070 0 NOTYPE GLOBAL DEFAULT ABS dlmisssize 569: 00100100 0 NOTYPE GLOBAL DEFAULT ABS kernbase 5103: 0020 0 NOTYPE GLOBAL DEFAULT ABS testppc64size 8156: 0018 0 NOTYPE GLOBAL DEFAULT ABS restorebridgesize 9078: 00b0 0 NOTYPE GLOBAL DEFAULT ABS imisssize 12351: 00f0 0 NOTYPE GLOBAL DEFAULT ABS dsmisssize 25923: 0070 0 NOTYPE GLOBAL DEFAULT ABS dlmisssize 26490: 00100100 0 NOTYPE GLOBAL DEFAULT ABS kernbase 31024: 0020 0 NOTYPE GLOBAL DEFAULT ABS testppc64size 34077: 0018 0 NOTYPE GLOBAL DEFAULT ABS restorebridgesize 34999: 00b0 0 NOTYPE GLOBAL DEFAULT ABS imisssize 38272: 00f0 0 NOTYPE GLOBAL DEFAULT ABS dsmisssize but the old ld produces a much longer list: # readelf -a /boot/kernel/kernel | grep "\" | more 2: 0070 0 NOTYPE GLOBAL DEFAULT ABS dlmisssize 212: 00e793dc 0 NOTYPE GLOBAL DEFAULT ABS __start_set_gfb_set 462: 00e793c8 0 NOTYPE GLOBAL DEFAULT ABS __start_set_mmu_set 569: 00100100 0 NOTYPE GLOBAL DEFAULT ABS kernbase 1334: 00dd5728 0 NOTYPE GLOBAL DEFAULT ABS __start_set_sdt_probes_set 1395: 00e5e608 0 NOTYPE GLOBAL DEFAULT ABS __start_set_vnet 1765: 01183648 0 NOTYPE GLOBAL DEFAULT ABS end 1798: 00dd36d0 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_sysinit_set 1857: 00dd4e34 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_modmetadata_set 2001: 00dd7984 0 NOTYPE GLOBAL DEFAULT ABS __start_set_uart_fdt_class_and_device_set 2271: 00dd5648 0 NOTYPE GLOBAL DEFAULT ABS __start_set_cam_xpt_proto_set 2384: 00dd561c 0 NOTYPE GLOBAL DEFAULT ABS __start_set_cam_xpt_xport_set 2669: 00dd407c 0 NOTYPE GLOBAL DEFAULT ABS __start_set_modmetadata_set 2746: 00dd9ef8 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_pcpu 3281: 00e793d8 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_videodriver_set 3324: 00e793d4 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_mmu_set 3365: 00e793c0 0 NOTYPE GLOBAL DEFAULT ABS __start_set_compressors 3430: 00dd7960 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_scterm_set 3573: 00dd5648 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_cam_xpt_xport_set 3892: 00dd5684 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_ofw_set 4195: 00dd7988 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_uart_fdt_class_and_device_set 4226: 00dd36d0 0 NOTYPE GLOBAL DEFAULT ABS __start_set_sysuninit_set 4322: 00dd7954 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_sdt_argtypes_set 4329: 00e793e0 0 NOTYPE GLOBAL DEFAULT ABS __start_set_platform_set 4571: 00dd7a00 0 NOTYPE GLOBAL DEFAULT ABS __start_set_pcpu 4676: 00dd7960 0 NOTYPE GLOBAL DEFAULT ABS __start_set_cons_set 4736: 00dd2468 0 NOTYPE GLOBAL DEFAULT ABS __start_set_sysinit_set 4880: 00100100 0 NOTYPE GLOBAL DEFAULT ABS begin 4919: 00dd56d0 0 NOTYPE GLOBAL DEFAULT ABS __start_set_sdt_providers_set 5094: 00dd7990 0 NOTYPE GLOBAL DEFAULT ABS __stop_s
32-bit powerpc kernel builds (head -r356187): old ld (works) vs. devel/binutils@powerpc based (fails to boot): DYNAMIC vs. EXEC_P
My attempt to buildkernel via devel/binutils@powerpc produces a kernel that gets a very early crash. Looking at the normal and alternate kernels a little shows. . . Old ld (and such): /boot/kernel/kernel: file format elf32-powerpc-freebsd /boot/kernel/kernel architecture: powerpc:common, flags 0x0150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x001001e0 . . . 00e7a034 l O *ABS* .hidden _DYNAMIC Produced via (from kernel.full.meta): CMD @ld -m elf32ppc_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc --secure-plt -pie --no-warn-mismatch --warn-common --export-dynamic --dynamic-linker /red/herring -X -o kernel.full locore.o . . . devel/binutils@powerpc based: /boot/kerbad/kernel: file format elf32-powerpc-freebsd /boot/kerbad/kernel architecture: powerpc:common, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x00100200 00e7a034 l O .dynamic _DYNAMIC Produced via (from kernel.full.meta): CMD @/usr/local/powerpc-unknown-freebsd13.0/bin/ld -m elf32ppc_fbsd -Bdynamic -T /usr/src/sys/conf/ldscript.powerpc --secure-plt --build-id=sha1 -pie --no-warn-mismatch --warn-common --export-dynamic --dynamic-linker /red/herring -X -o kernel.full locore.o . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: system-clang (elfv2) and devel/binutil@powerpc (32-bit): booting fail very early on PowerMac3,6 example ; also build problem why I tried this
On 2019-Dec-30, at 18:14, Mark Millard wrote: > Because of the (cross-)build failure (from amd64): > > --- acl_nfs4.ko.full --- > ld: acl_nfs4.kld(.text+0x234): R_PPC_PLTREL24 reloc against local symbol > acl_nfs4.kld: could not read symbols: Bad value > *** [acl_nfs4.ko.full] Error code 1 I found something from my old experimental clang build environment for 32-bit powerpc that I'd missed undoing when I tried to put things back to normal. It turned out to be the reason that R_PPC_PLTREL24 was being generated: -mlongcall was missing in my build. (There was a time that clang did not have it but gcc did, so I had it conditional in my old, experimental environment.) With -mlongcall back in place as normal (not just for gcc), system-clang with old ld (cross build) completes buildworld buildkernel . The old 32-bit PowerMac is running an official modern-compiler-based system at last! Cool. Thanks. Sorry for the noise. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
system-clang (elfv2) and devel/binutil@powerpc (32-bit): booting fail very early on PowerMac3,6 example ; also build problem why I tried this
(There are later notes below with build failure information that lead me to try devel/binutils@powerpc .) Because of the (cross-)build failure (from amd64): --- acl_nfs4.ko.full --- ld: acl_nfs4.kld(.text+0x234): R_PPC_PLTREL24 reloc against local symbol acl_nfs4.kld: could not read symbols: Bad value *** [acl_nfs4.ko.full] Error code 1 when using the default ld for 32-bit powerpc, I tried using devel/binutil@powerpc for which buildworld buildkernel at least ran to completion. The build was of a non-debug kernel (and world), but with symbols. But the result failed to boot, stopping very early: (typed from a image) . . . Booted from: /pci@f400/ata-6@d/disk@0 Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0xd97874+0x2ebdd4 syms=[0x4+0x97740+0x4+0xc34d2] Invalid memory access at %SRR0: 04C0 %SRR1: c000 Apple PowerMac3,6 4.6.0f1 BootROM built on 02/20/03 at 13:52:27 . . . As for the build failure . . . # Meta data file /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/acl_nfs4/acl_nfs4.kld.meta CMD ld -m elf32ppc_fbsd --secure-plt -d -warn-common -r -d -o acl_nfs4.kld subr_acl_nfs4.o CMD ctfmerge -L VERSION -g -o acl_nfs4.kld subr_acl_nfs4.o CMD :> export_syms CMD awk -f /usr/src/sys/conf/kmod_syms.awk acl_nfs4.kld export_syms | xargs -J% objcopy % acl_nfs4.kld CWD /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG/modules/usr/src/sys/modules/acl_nfs4 TARGET acl_nfs4.kld . . . >From readelf -a for the subr_acl_nfs4.o : (acl_nfs4_sync_mode_from_acl is GLOBAL here) . . . Relocation section with addend (.rela.text): r_offset r_info r_type st_value st_name + r_addend 0076 14fc .got2 + 8022 007a 14fa .got2 + 8026 01ac 3112 R_PPC_PLTREL24 groupmember + 8000 0234 3012 R_PPC_PLTREL24 0458 acl_nfs4_sync_mode_from_acl + 8000 02c4 3312 R_PPC_PLTREL24 priv_check_cred + 8000 02f4 3312 R_PPC_PLTREL24 priv_check_cred + 8000 032c 3312 R_PPC_PLTREL24 priv_check_cred + 8000 0360 3312 R_PPC_PLTREL24 priv_check_cred + 8000 038c 3312 R_PPC_PLTREL24 priv_check_cred + 8000 07c6 14fc .got2 + 800a 07ca 14fa .got2 + 800e 1026 14fc .got2 + 8006 102a 14fa .got2 + 800a 1676 14fc .got2 + 800a 167a 14fa .got2 + 800e 1698 2a12 R_PPC_PLTREL24 acl_alloc + 8000 16a8 3012 R_PPC_PLTREL24 0458 acl_nfs4_sync_mode_from_acl + 8000 1748 2b12 R_PPC_PLTREL24 acl_free + 8000 17e8 2b12 R_PPC_PLTREL24 acl_free + 8000 183a 14fc .got2 + 800a 183e 14fa .got2 + 800e . . . Relocation section with addend (.rela.text): r_offset r_info r_type st_value st_name + r_addend . . . 47: 07a0 128 FUNCGLOBAL DEFAULT2 acl_nfs4_sync_acl_from_mode 48: 0458 840 FUNCGLOBAL DEFAULT2 acl_nfs4_sync_mode_from_acl 49: 0 NOTYPE GLOBAL DEFAULT UND groupmember . . . But after: CMD ld -m elf32ppc_fbsd --secure-plt -d -warn-common -r -d -o acl_nfs4.kld subr_acl_nfs4.o CMD ctfmerge -L VERSION -g -o acl_nfs4.kld subr_acl_nfs4.o CMD :> export_syms CMD awk -f /usr/src/sys/conf/kmod_syms.awk acl_nfs4.kld export_syms | xargs -J% objcopy % acl_nfs4.kld >From readelf -a for the acl_nfs4.kld : (acl_nfs4_sync_mode_from_acl is LOCAL here) . . . Relocation section with addend (.rela.text): r_offset r_info r_type st_value st_name + r_addend . . . 0076 04fc .got2 + 8022 007a 04fa .got2 + 8026 01ac 3012 R_PPC_PLTREL24 groupmember + 8000 0234 2c12 R_PPC_PLTREL24 0458 acl_nfs4_sync_mode_from_acl + 8000 02c4 3212 R_PPC_PLTREL24 priv_check_cred + 8000 02f4 3212 R_PPC_PLTREL24 priv_check_cred + 8000 032c 3212 R_PPC_PLTREL24 priv_check_cred + 8000 0360 3212 R_PPC_PLTREL24 priv_check_cred + 8000 038c 3212 R_PPC_PLTREL24 priv_check_cred + 8000 07c6 04fc .got2 + 800a 07ca 04fa .got2 + 800e 1026 04fc .got2 + 8006 102a 04fa .got2 + 800a 1676 04fc .got2 + 800a 167a 04fa .got2 + 800e 1698 3c12 R_PPC_PLTREL24 acl_alloc + 8000 16a8 2c12 R_PPC_PLTREL24 0458 acl_nfs4_sync_mode_from_acl + 8000 1748 3912 R_PPC_PLTREL24 acl_free + 8000 17e8 3912 R_PPC_PLTREL24 acl_free + 8000 183a
devel/binutils@powerpc64 ( powerpc64-unknown-freebsd13.0-ld ) unbounded loop in bfd/elf64-ppc.c : the source code and values
I ran into the following ubounded loop
(via the continue) in bfd/elf64-ppc.c
while trying to do a
devel/freebsd-gcc9@powerpc64 based
buildworld buildkernel :
/* Read the relocations. */
relstart = _bfd_elf_link_read_relocs (ibfd, sec, NULL, NULL,
info->keep_memory);
if (relstart == NULL)
return FALSE;
relend = relstart + sec->reloc_count;
for (rel = relstart; rel < relend; )
{
enum elf_ppc64_reloc_type r_type;
unsigned long r_symndx;
asection *sym_sec;
struct elf_link_hash_entry *h;
Elf_Internal_Sym *sym;
unsigned char *tls_maskp;
r_type = ELF64_R_TYPE (rel->r_info);
if (r_type != R_PPC64_PLTCALL
&& r_type != R_PPC64_PLTCALL_NOTOC)
continue;
Nothing is done before the continue to make rel
progress towards relend (or relend towards
relstart). It just repeats the same activity
over and over on the same rel value.
This was in:
devel/binutils/work-powerpc64/binutils-2.33.1/bfd/elf64-ppc.c
The 1st line quoted above was line 7455 according to vi.
Ref reference, both of the stuck links (clang.full and
lld.full) have:
(gdb) print r_type
$1 = R_PPC64_REL16_HA
(gdb) print/x *rel
$3 = {r_offset = 0x2, r_info = 0x1800fc, r_addend = 0x2}
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Building head -r356187 for powerpc64 via devel/freebsd-gcc9 fails: powerpc64-unknown-freebsd13.0-ld: over 480 cpu minutes on ThreadRipper 1950X
There are two nearly 100% cpu usage instances of
powerpc64-unknown-freebsd13.0-ld , each with over
480 cpu minutes, one for clang.full and one for
lld.full . (amd64->powerpc64 cross build.)
The below shows the file system view of the status
after all that time: 0 size .full files.
# ls -ldTt
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full*
| head
-rw-r--r-- 1 root wheel 3071 Dec 30 00:30:02 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full.meta
-rw-r--r-- 1 root wheel 0 Dec 30 00:29:32 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full
# ls -ldTt
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full*
| head
-rw-r--r-- 1 root wheel 3071 Dec 30 00:30:02 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full.meta
-rw-r--r-- 1 root wheel 0 Dec 30 00:29:32 2019
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/clang/clang.full
Attaching to one of them with gdb shows
(I build ports optimized but with symbols generally):
(gdb) bt
#0 0x0035431d in ppc64_elf_inline_plt (info=) at
elf64-ppc.c:7473
#1 0x0032acb0 in ppc_before_allocation () at eelf64ppc_fbsd.c:370
#2 0x00319651 in lang_process () at ldlang.c:7678
#3 0x003208d8 in main (argc=, argv=) at
./ldmain.c:441
ppc64_elf_inline_plt does not return (finish
does not stop on its own).
Using step shows:
(gdb) step
7471in elf64-ppc.c
(gdb)
7473in elf64-ppc.c
(gdb)
7471in elf64-ppc.c
(gdb)
7473in elf64-ppc.c
. . .
Looking at the instruction level:
(gdb) display/i $pc
1: x/i $pc
=> 0x35431d : jne0x354310
(gdb) nexti
7471in elf64-ppc.c
1: x/i $pc
=> 0x354310 : mov0x8(%r13),%r12
(gdb)
7473in elf64-ppc.c
1: x/i $pc
=> 0x354314 : mov%r12d,%eax
(gdb)
0x00354317 7473in elf64-ppc.c
1: x/i $pc
=> 0x354317 : or $0x2,%eax
(gdb)
0x0035431a 7473in elf64-ppc.c
1: x/i $pc
=> 0x35431a : cmp$0x7a,%eax
(gdb)
0x0035431d 7473in elf64-ppc.c
1: x/i $pc
=> 0x35431d : jne0x354310
(gdb)
7471in elf64-ppc.c
1: x/i $pc
=> 0x354310 : mov0x8(%r13),%r12
(gdb)
7473in elf64-ppc.c
1: x/i $pc
=> 0x354314 : mov%r12d,%eax
(gdb)
0x00354317 7473in elf64-ppc.c
1: x/i $pc
=> 0x354317 : or $0x2,%eax
(gdb)
0x0035431a 7473in elf64-ppc.c
1: x/i $pc
=> 0x35431a : cmp$0x7a,%eax
(gdb)
0x0035431d 7473in elf64-ppc.c
1: x/i $pc
=> 0x35431d : jne0x354310
. . .
To do the experiment I built devel/freebsd-gcc9 based on:
( ports at -r520539 )
# svnlite diff /usr/ports/devel/freebsd-gcc9/
Index: /usr/ports/devel/freebsd-gcc9/Makefile
===
--- /usr/ports/devel/freebsd-gcc9/Makefile (revision 520539)
+++ /usr/ports/devel/freebsd-gcc9/Makefile (working copy)
@@ -53,6 +53,10 @@
--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
+.if ${TARGETARCH} == powerpc64
+CONFIGURE_ARGS+=--with-abi=elfv2
+.endif
+
ALL_TARGET=all-gcc
INSTALL_TARGET=install-gcc
(So I forced elfv2 for powerpc64.)
I'm also using WITHOUT_LIB32 to avoid the
the forced bss-plt that ends up involved:
It stops the build:
# svnlite diff /usr/src/share/mk/bsd.cpu.mk
Index: /usr/src/share/mk/bsd.cpu.mk
===
--- /usr/src/share/mk/bsd.cpu.mk(revision 356187)
+++ /usr/src/share/mk/bsd.cpu.mk(working copy)
@@ -421,7 +421,7 @@
# normal builds works when CROSS_BINUTILS_PREFIX and could be removed
# when LLD PowerPC 32 bit support is completed
.if defined(CROSS_BINUTILS_PREFIX)
-LD_BFD=${LOCALBASE}/bin/${CROSS_BINUTILS_PREFIX}-ld.bfd
+LD_BFD=${CROSS_BINUTILS_PREFIX}ld.bfd
.else
LD_BFD=${OBJTOP}/tmp/usr/bin/ld.bfd
.endif
(The above change used a working file path.)
I used:
# more ~/src.configs/src.conf.powerpc64-xtoolchain-gcc.amd64-host
GCCVERSION=9
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=13.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
WITHOUT_SYSTEM_LINKER=
#
WITH_LLVM_LIBUNWIND=
WITH_LIBCPLUSPLUS=
WITHOUT_LLD_BOOTSTRAP=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_LLVM_TARGET_ALL=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITHOUT_BINUTILS=
#WITH_PORT_BASE_BINUTILS=
# Note: LLDB fails to build (link).
WITHOUT_LLDB=
#
WITH_BOOT=
#
# Fails to build
LDFLAGS.lld+= vs. 32-bit powerpc related use of ld.bfd in a powerpc64 overall build (head -r356187)
I have historically used the likes of: # grep -r no-threads /etc/ /etc/make.conf:LDFLAGS.lld+= -Wl,--no-threads But in trying to build for powerpc64 there is some 32-bit linking as well and it gets the above involved despite the .lld in the notation. LDFLAGS.lld being involved at all for a non-lld based link is the important point, not that I happened to use --no-threads . The first error report in the attempted build was: --- boot1.elf --- /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin/ld.bfd: unrecognized option '--no-threads' /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin/ld.bfd: use the --help option for usage information cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [boot1.elf] Error code 1 make[5]: stopped in /usr/src/stand/powerpc/boot1.chrp .ERROR_TARGET='boot1.elf' .ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/stand/powerpc/boot1.chrp/boot1.elf.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='cc -target powerpc64-unknown-freebsd13.0 --sysroot=/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp -B/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin -O2 -pipe -nostdinc -I/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/stand/libsa -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_DISK_SUPPORT -m32 -mcpu=powerpc -fuse-ld=/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin/ld.bfd -ffreestanding -msoft-float -I. -Iinclude -I/usr/src/stand/common -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted- parameter -Wno-parentheses -Qunused-arguments -nostdlib -static -Wl,-N -Wl,--no-threads -o boot1.elf boot1.o qdivrem.o udivdi3.o ashldi3.o syncicache.o ;' .CURDIR='/usr/src/stand/powerpc/boot1.chrp' .MAKE='make' .OBJDIR='/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/stand/powerpc/boot1.chrp' .TARGETS='all' DESTDIR='/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp' LD_LIBRARY_PATH='' MACHINE='powerpc' MACHINE_ARCH='powerpc64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.powerpc64-clang-bootstrap.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/stand/powerpc/boot1.chrp/Makefile /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/stand/powerpc/boot1.chrp/../Makefile.inc /usr/src/stand/powerpc/boot1.chrp/../../Makefile.inc /usr/src/stand/powerpc/boot1.chrp/../../defs.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/stand/powerpc/boot1.chrp/Makefile.hfs /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk /src.libnames.mk /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/powerpc/boot1.chrp /usr/src/sys/libkern /usr/src/lib/libc/powerpc/gen /usr/src/stand/powerpc/boot1.chrp' 1 error === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@fre
x11-toolkits/qt5-gui build on/for Cortex-A7 ( head -r356109 ) failed with: unable to execute command: Executable "as" doesn't exist
Is system-clang 9.0.1 supposed to implicitly try to use
/usr/local/bin/as ? It does for this context . . .
Note the -fno-integrated-as use in the later quoted log material.
I'll also note that an experiment via -### shows that system-clang
9.0.1 then uses a command like (from a very simple example test):
"/usr/local/bin/as" "-mfpu=vfp" "-meabi=5" "-o" "a.o" "/tmp/a-14ae2e.s"
and that in turn presumes that devel/binutils has provided
/usr/local/bin/as .
That in turn means that, for ports-mgmt/poudriere-devel to
work for x11-toolkits/qt5-gui ,
BUILD_DEPENDS= at-spi2-core>=0:accessibility/at-spi2-core \
${LOCALBASE}/include/linux/input.h:devel/evdev-proto \
${LOCALBASE}/include/vulkan/vulkan.h:devel/vulkan-headers
would need to also include (or the @native explicita-flavor variant):
${LOCALBASE}/bin/as:devel/binutils
HOWEVER, I'm not sure if the implicit use of /usr/local/bin/as
is intentional or not for system-clang.
The failure report (1st error only, there were more):
. . .
--- .obj/pixman-arm-neon-asm.o ---
cc -c -O2 -pipe -mcpu=cortex-a7 -g -fstack-protector-strong -isystem
/usr/local/include -fno-strict-aliasing -std=gnu11 -fvisibility=hidden
-fno-exceptions -Wall -W -pthread -fPIC -DQT_ACCESSIBILITY -DQT_DBUS
-DQT_FONTCONFIG -DQT_FREETYPE -DQT_GLIB -DQT_IMAGEFORMAT_PNG -DQT_OPENGL
-DQT_SHAPE -DQT_XCB -DQT_XKB -DQT_XKBCOMMON -DQT_XRENDER
-DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWHELPERS
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -fno-integrated-as -I.
-I../../include -I../../include/QtGui -I../../include/QtGui/5.13.2
-I../../include/QtGui/5.13.2/QtGui -I.tracegen -isystem
/usr/local/include/libdrm -isystem /usr/local/include/qt5/QtCore/5.13.2
-isystem /usr/local/include/qt5/QtCore/5.13.2/QtCore -isystem /usr/lo
cal/include/qt5 -isystem /usr/local/include/qt5/QtCore -I.moc -isystem
/usr/local/include/libpng16 -isystem /usr/local/include
-I/usr/local/lib/qt5/mkspecs/freebsd-clang
../3rdparty/pixman/pixman-arm-neon-asm.S -o .obj/pixman-arm-neon-asm.o
. . .
--- .obj/pixman-arm-neon-asm.o ---
cc: error: unable to execute command: Executable "as" doesn't exist!
cc: error: assembler command failed with exit code 1 (use -v to see invocation)
*** [.obj/pixman-arm-neon-asm.o] Error code 1
make[1]: stopped in
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.2/src/gui
. . .
For reference:
Build based on ports-mgmt/pooudriere-devel .
>From early in the log, showing compiler information:
/usr/ports/Mk/Scripts/ports_env.sh
_CCVERSION_921dbbb2=FreeBSD clang version 9.0.1
(g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) Target:
armv7-unknown-freebsd13.0-gnueabihf Thread model: posix InstalledDir: /usr/bin
_ALTCCVERSION_921dbbb2=none
_CXXINTERNAL_acaad9ca=FreeBSD clang version 9.0.1
(g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) Target:
armv7-unknown-freebsd13.0-gnueabihf Thread model: posix InstalledDir: /usr/bin
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1"
"--hash-style=both" "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o"
"/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/dev/null" "-lc++" "-lm"
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed"
"-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"
CC_OUTPUT_921dbbb2_58173849=yes
CC_OUTPUT_921dbbb2_9bdba57c=yes
CC_OUTPUT_921dbbb2_6a4fe7f5=yes
CC_OUTPUT_921dbbb2_6bcac02b=yes
CC_OUTPUT_921dbbb2_67d20829=yes
CC_OUTPUT_921dbbb2_bfa62e83=yes
CC_OUTPUT_921dbbb2_f0b4d593=yes
CC_OUTPUT_921dbbb2_308abb44=yes
CC_OUTPUT_921dbbb2_f00456e5=yes
CC_OUTPUT_921dbbb2_65ad290d=yes
CC_OUTPUT_921dbbb2_f2776b26=yes
CC_OUTPUT_921dbbb2_b2657cc3=yes
CC_OUTPUT_921dbbb2_380987f7=yes
CC_OUTPUT_921dbbb2_160933ec=yes
CC_OUTPUT_921dbbb2_fb62803b=yes
_OBJC_CCVERSION_921dbbb2=FreeBSD clang version 9.0.1
(g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) Target:
armv7-unknown-freebsd13.0-gnueabihf Thread model: posix InstalledDir: /usr/bin
_OBJC_ALTCCVERSION_921dbbb2=none
ARCH=armv7
OPSYS=FreeBSD
_OSRELEASE=13.0-CURRENT
OSREL=13.0
OSVERSION=1300069
PYTHONBASE=/usr/local
_SMP_CPUS=4
CONFIGURE_MAX_CMD_LEN=262144
HAVE_PORTS_ENV=1
# uname -apKU
FreeBSD OPiP2E 13.0-CURRENT FreeBSD 13.0-CURRENT #12 r356109M: Fri Dec 27
17:24:56 PST 2019
markmi@FBSDFHUGE:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENERIC-NODBG
arm armv7 1300069 1300069
# cc -v
FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM
devel/aarch64-none-elf-gcc build failed with long list of "pkg-static: Unable to access file . . ." during package stage
In attempting a devel/aarch64-none-elf-gcc build (in a amd64->armv7 cross-build context), it failed with: === ===> Building package for aarch64-none-elf-gcc-6.4.0_7 pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/gtype.state:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No such file or direct ory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/addresses.h:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/alias.h:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/all-tree.def:No such file or directory . . . (long list) . . . pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/wide-int.h:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/xcoff.h:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/plugin/include/xcoffout.h:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/libexec/gcc/aarch64-none-elf/6.4.0/plugin/gengtype:No such file or directory *** Error code 1 Stop. make: stopped in /usr/ports/devel/aarch64-none-elf-gcc =>> Cleaning up wrkdir ===> Cleaning for aarch64-none-elf-gcc-6.4.0_7 build of devel/aarch64-none-elf-gcc | aarch64-none-elf-gcc-6.4.0_7 ended at Sat Dec 28 04:40:12 PST 2019 FreeBSD head -r356109 based context. ports -r520539 based context. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
base/binutils build on 32-bit powerpc fails for not finding elf64_fbsd.* ldscripts
In a 32-bit powerpc environment (head -r356066 or so, clang based), I attempted to "make package" (not a cross build) for /usr/ports/base/binutils ( as of ports -r520539 ) and the end result was failures to find 64-bit ldscripts: ===> Building package for freebsd-binutils-2.33.1 pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.x:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xbn:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xd:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xdc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xdw:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xn:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xr:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xs:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xsc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xsw:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xu:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc_fbsd.xw:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.x:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xbn:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xd:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xdc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xdw:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xn:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xr:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xs:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xsc:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xsw:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xu:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/base/binutils/work/stage/usr/powerpc-unknown-freebsd13.0/lib/ldscripts/elf64ppc.xw:No such file or directory *** Error code 1 For reference, the attempt built (or for binutils tried to): # ls -ldT /wrkdirs/usr/ports/*/* drwxr-xr-x 3 root wheel 512 Dec 28 02:04:11 2019 /wrkdirs/usr/ports/base/binutils drwxr-xr-x 3 root wheel 512 Dec 28 02:04:55 2019 /wrkdirs/usr/ports/devel/gettext-runtime drwxr-xr-x 3 root wheel 512 Dec 28 02:04:38 2019 /wrkdirs/usr/ports/devel/gmake drw
Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang
On 2019-Dec-26, at 20:49, Gerald Pfeifer wrote: > On Thu, 26 Dec 2019, Mark Millard wrote: >> I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an >> ELFv1 clang environment) and it reported (listing just one of the >> examples that pointed to vec_step): > > I maintain this is a bug in clang which should be address there. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239266 I wish they would, but . . . Unfortunately, this is likely a hard sell to the upstream clang folks because https://www.nxp.com/docs/en/reference-manual/ALTIVECPIM.pdf defines vec_step in "2.5.3 Value for Adjusting Pointers" and does not bother with specifying language namespace niceties, as I remember. That dates back to 1999-June. (The "POWER expert" quoted in comment 11 was wrong about the Altivec PIM not having a definition.) Clang has been this way for a long time and ends up considering how many AltiVec related builds would be broken by such a breaking change for those builds. The later OpenCL specification of its vec_step has the same sort of status as I remember. Thus, the same type of considerations likely are involved again. So I expect that, if devel/freebsd-gcc[69] waits for clang to be fixed, instead of having a (hopefully temporary) workaround, then for a significant time those ports likely will not work for being built via clang for targeting powerpc64 or powerpc. An unfortunate context, for sure. >> It turns out that: >> >> # ls -laT /usr/ports/devel/freebsd-gcc9/files/ >> total 44 >> drwxr-xr-x 2 root wheel512 Dec 25 19:25:26 2019 . >> drwxr-xr-x 3 root wheel512 Dec 25 19:25:26 2019 .. >> -rw-r--r-- 1 root wheel 4781 Dec 25 19:25:26 2019 >> patch-freebsd-format-extensions >> -rw-r--r-- 1 root wheel 1413 Dec 25 19:25:26 2019 patch-freebsd-libdir >> -rw-r--r-- 1 root wheel588 Dec 25 19:25:26 2019 patch-gcc-configure >> -rw-r--r-- 1 root wheel 16346 Dec 25 19:25:26 2019 patch-gcc-freebsd-mips >> -rw-r--r-- 1 root wheel231 Dec 25 19:25:26 2019 xtoolchain.mk.in >> >> is missing the patch-clang-vec_step that is in: >> >> FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ > > That is a hack that can be used to work around the issue; I strongly > recommend addressing this in clang properly, though. > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
A devel/freebsd-gcc*/Makefile suggestion to avoid base/binutil preventing freebsd-gcc* builds
Context: devel/freebsd-gcc* (for example)
using:
--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
The likes of ${BU_PREFIX}-ld possibly also
exists someplace else on the path in use.
So I suggest that the BUILD_DEPENDS and
RUN_DEPENDS cause the full path to be
checked so that the full path will be
created if they do not exist already.
So, using devel/freebsd-gcc9 as an example,
. . .
# svnlite diff /usr/ports/devel/freebsd-gcc9/
Index: /usr/ports/devel/freebsd-gcc9/Makefile
===
--- /usr/ports/devel/freebsd-gcc9/Makefile (revision 520539)
+++ /usr/ports/devel/freebsd-gcc9/Makefile (working copy)
@@ -16,8 +16,8 @@
LIB_DEPENDS= libgmp.so:math/gmp \
libmpfr.so:math/mpfr \
libmpc.so:math/mpc
-BUILD_DEPENDS= ${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
-RUN_DEPENDS= ${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
+BUILD_DEPENDS= ${LOCALBASE}/bin/${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
+RUN_DEPENDS=${LOCALBASE}/bin/${BU_PREFIX}-as:devel/binutils@${TARGETARCH}
FLAVORS= aarch64 amd64 i386 mips mips64 powerpc powerpc64 riscv64 sparc64
TARGETARCH=${FLAVOR}
This avoids later not finding the file via
the full path in such contexts.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang
On 2019-Dec-26, at 15:21, Mark Millard wrote: > I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an > ELFv1 clang environment) and it reported (listing just one of the > examples that pointed to vec_step): > > > /wrkdirs/usr/ports/devel/freebsd-gcc9/work-powerpc/gcc-9.2.0/gcc/tree-vect-loop.c:4595:12: > error: expected unqualified-id > tree vec_step = build_vector_from_val (cr_index_vector_type, step); > ^ > > (Unsure if white handling will still end up with ^ > pointing to vec_step.) > > clang reserves a name that the gcc source code uses: > vec_step . (I'll not get into the long, messy history > of this name and multiple standards built on top of > C/C++, not necessarily in a language appropriate > way.) > > It turns out that: > > # ls -laT /usr/ports/devel/freebsd-gcc9/files/ > total 44 > drwxr-xr-x 2 root wheel512 Dec 25 19:25:26 2019 . > drwxr-xr-x 3 root wheel512 Dec 25 19:25:26 2019 .. > -rw-r--r-- 1 root wheel 4781 Dec 25 19:25:26 2019 > patch-freebsd-format-extensions > -rw-r--r-- 1 root wheel 1413 Dec 25 19:25:26 2019 patch-freebsd-libdir > -rw-r--r-- 1 root wheel588 Dec 25 19:25:26 2019 patch-gcc-configure > -rw-r--r-- 1 root wheel 16346 Dec 25 19:25:26 2019 patch-gcc-freebsd-mips > -rw-r--r-- 1 root wheel231 Dec 25 19:25:26 2019 xtoolchain.mk.in > > is missing the patch-clang-vec_step that is in: > > FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ > total 32 > drwxr-xr-x 2 root wheel 512 Dec 25 20:57:52 2019 . > drwxr-xr-x 3 root wheel 512 Dec 25 21:07:33 2019 .. > -rw-r--r-- 1 root wheel 3450 Jun 1 18:44:50 2019 > patch-arm-unwind-cxx-support > -rw-r--r-- 1 root wheel 651 Sep 18 11:08:37 2019 patch-clang-vec_step > -rw-r--r-- 1 root wheel 2148 Jun 1 18:44:50 2019 patch-gets-no-more > -rw-r--r-- 1 root wheel 2897 Jun 1 18:44:50 2019 patch-gfortran-libgcc > -rw-r--r-- 1 root wheel 932 Dec 25 19:25:10 2019 patch-powerpc32 > -rw-r--r-- 1 root wheel 294 Sep 15 13:10:46 2019 pkg-message.in > > I do not know if other differences in the patch > lists might be important to other aspects (in > either direction). I should have also noted that devel/freebsd-gcc6 has the same issue: # ls -laT /usr/ports/devel/freebsd-gcc6/files/ total 44 drwxr-xr-x 2 root wheel512 Dec 25 19:25:37 2019 . drwxr-xr-x 3 root wheel512 Dec 25 19:25:37 2019 .. -rw-r--r-- 1 root wheel 4657 Dec 25 19:25:37 2019 patch-freebsd-format-extensions -rw-r--r-- 1 root wheel 1413 Dec 25 19:25:37 2019 patch-freebsd-libdir -rw-r--r-- 1 root wheel 16435 Dec 25 19:25:37 2019 patch-gcc-freebsd-mips -rw-r--r-- 1 root wheel204 Dec 25 19:25:37 2019 xtoolchain.mk.in It also needs patch-clang-vec_step (or some equivalent) for powerpc and powerpc64 targeting to compile via clang, because of clang reserving the vec_step identifier and the gcc source code using that identifier. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang
I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an ELFv1 clang environment) and it reported (listing just one of the examples that pointed to vec_step): /wrkdirs/usr/ports/devel/freebsd-gcc9/work-powerpc/gcc-9.2.0/gcc/tree-vect-loop.c:4595:12: error: expected unqualified-id tree vec_step = build_vector_from_val (cr_index_vector_type, step); ^ (Unsure if white handling will still end up with ^ pointing to vec_step.) clang reserves a name that the gcc source code uses: vec_step . (I'll not get into the long, messy history of this name and multiple standards built on top of C/C++, not necessarily in a language appropriate way.) It turns out that: # ls -laT /usr/ports/devel/freebsd-gcc9/files/ total 44 drwxr-xr-x 2 root wheel512 Dec 25 19:25:26 2019 . drwxr-xr-x 3 root wheel512 Dec 25 19:25:26 2019 .. -rw-r--r-- 1 root wheel 4781 Dec 25 19:25:26 2019 patch-freebsd-format-extensions -rw-r--r-- 1 root wheel 1413 Dec 25 19:25:26 2019 patch-freebsd-libdir -rw-r--r-- 1 root wheel588 Dec 25 19:25:26 2019 patch-gcc-configure -rw-r--r-- 1 root wheel 16346 Dec 25 19:25:26 2019 patch-gcc-freebsd-mips -rw-r--r-- 1 root wheel231 Dec 25 19:25:26 2019 xtoolchain.mk.in is missing the patch-clang-vec_step that is in: FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ total 32 drwxr-xr-x 2 root wheel 512 Dec 25 20:57:52 2019 . drwxr-xr-x 3 root wheel 512 Dec 25 21:07:33 2019 .. -rw-r--r-- 1 root wheel 3450 Jun 1 18:44:50 2019 patch-arm-unwind-cxx-support -rw-r--r-- 1 root wheel 651 Sep 18 11:08:37 2019 patch-clang-vec_step -rw-r--r-- 1 root wheel 2148 Jun 1 18:44:50 2019 patch-gets-no-more -rw-r--r-- 1 root wheel 2897 Jun 1 18:44:50 2019 patch-gfortran-libgcc -rw-r--r-- 1 root wheel 932 Dec 25 19:25:10 2019 patch-powerpc32 -rw-r--r-- 1 root wheel 294 Sep 15 13:10:46 2019 pkg-message.in I do not know if other differences in the patch lists might be important to other aspects (in either direction). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: For devel/freebsd-gcc9@powerpc64 and devel/binutils@powerpc64 use: internal compiler error: in rs6000_pltseq_template, at config/rs6000/rs6000.c:21873
On 2019-Dec-21, at 16:40, Mark Millard wrote: > This was for a amd64->powerpc64 buildworld for a head > -r355976 based context. > > The there is lots of command argument information from > the gcc toolchain being used with -v. The .meta report > also shows such. > > ===> lib/csu/powerpc64 (all) > Building > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/crt1.s > Using built-in specs. > COLLECT_GCC=/usr/local/bin/powerpc64-unknown-freebsd13.0-gcc9 > Target: powerpc64-unknown-freebsd13.0 > Configured with: > /wrkdirs/usr/ports/devel/freebsd-gcc9/work-powerpc64/gcc-9.2.0/configure > --target=powerpc64-unknown-freebsd13.0 --disable-nls --enable-languages=c,c++ > --enable-gnu-indirect-function --enable-initfini-array > --program-prefix=powerpc64-unknown-freebsd13.0- --program-suffix=9 > --without-headers --with-gmp=/usr/local --with-pkgversion='FreeBSD Ports > Collection for powerpc64' --with-system-zlib > --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/ > --with-as=/usr/local/bin/powerpc64-unknown-freebsd13.0-as > --with-ld=/usr/local/bin/powerpc64-unknown-freebsd13.0-ld --prefix=/usr/local > --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ > --build=x86_64-unknown-freebsd13.0 > Thread model: posix > gcc version 9.2.0 (FreeBSD Ports Collection for powerpc64) > COLLECT_GCC_OPTIONS='-gdwarf-2' '-B' > '/usr/local/powerpc64-unknown-freebsd13.0/bin/' '-O2' '-pipe' '-I' > '/usr/src/lib/csu/powerpc64' '-I' '/usr/src/lib/csu/common' '-I' > '/usr/src/lib/libc/include' '-mlongcall' '-D' 'CRT_IRELOC_RELA' '-g' > '-std=gnu99' '-Wno-format-zero-length' '-Wsystem-headers' '-Wall' > '-Wno-format-y2k' '-Wextra' '-Wstrict-prototypes' '-Wmissing-prototypes' > '-Wpointer-arith' '-Wreturn-type' '-Wcast-qual' '-Wwrite-strings' '-Wswitch' > '-Wshadow' '-Wunused-parameter' '-Wcast-align' '-Wchar-subscripts' '-Winline' > '-Wnested-externs' '-Wredundant-decls' '-Wold-style-definition' > '-Wno-pointer-sign' '-Wno-error=address' '-Wno-error=array-bounds' > '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align' > '-Wno-error=clobbered' '-Wno-error=deprecated-declarations' > '-Wno-error=enum-compare' '-Wno-error=extra' '-Wno-error=inline' > '-Wno-error=logical-not-parentheses' '-Wno-error=strict-aliasing' > '-Wno-error=uninitialized' '-Wno-error=unused-but-set-variable' '-Wn o-error=unused-function' '-Wno-error=unused-value' '-Wno-error=misleading-indentation' '-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value' '-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-Wno-error=bool-operation' '-Wno-error=deprecated' '-Wno-error=expansion-to-defined' '-Wno-error=format-overflow' '-Wno-error=format-truncation' '-Wno-error=implicit-fallthrough' '-Wno-error=int-in-bool-context' '-Wno-error=memset-elt-size' '-Wno-error=noexcept-type' '-Wno-error=nonnull' '-Wno-error=pointer-compare' '-Wno-error=stringop-overflow' '-Wno-error=aggressive-loop-optimizations' '-Wno-error=cast-function-type' '-Wno-error=catch-value' '-Wno-error=multistatement-macros' '-Wno-error=restrict' '-Wno-error=sizeof-pointer-memaccess' '-Wno-error=stringop-truncation' '-v' '-S' '-o' 'crt1.s' > /usr/local/libexec/gcc/powerpc64-unknown-freebsd13.0/9.2.0/cc1 -quiet -v -I > /usr/src/lib/csu/powerpc64 -I /usr/src/lib/csu/common -I > /usr/src/lib/libc/include -isysroot > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -D CRT_IRELOC_RELA /usr/src/lib/csu/powerpc64/crt1.c -quiet -dumpbase crt1.c > -mlongcall -auxbase-strip crt1.s -gdwarf-2 -g -O2 -Wno-format-zero-length > -Wsystem-headers -Wall -Wno-format-y2k -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wno-error=address > -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare > -Wno-error=cast-align -Wno-error=clobbered -Wno-error=deprecated-declarations > -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline > -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wn o-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-va
For devel/freebsd-gcc9@powerpc64 and devel/binutils@powerpc64 use: internal compiler error: in rs6000_pltseq_template, at config/rs6000/rs6000.c:21873
This was for a amd64->powerpc64 buildworld for a head -r355976 based context. The there is lots of command argument information from the gcc toolchain being used with -v. The .meta report also shows such. ===> lib/csu/powerpc64 (all) Building /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/crt1.s Using built-in specs. COLLECT_GCC=/usr/local/bin/powerpc64-unknown-freebsd13.0-gcc9 Target: powerpc64-unknown-freebsd13.0 Configured with: /wrkdirs/usr/ports/devel/freebsd-gcc9/work-powerpc64/gcc-9.2.0/configure --target=powerpc64-unknown-freebsd13.0 --disable-nls --enable-languages=c,c++ --enable-gnu-indirect-function --enable-initfini-array --program-prefix=powerpc64-unknown-freebsd13.0- --program-suffix=9 --without-headers --with-gmp=/usr/local --with-pkgversion='FreeBSD Ports Collection for powerpc64' --with-system-zlib --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/ --with-as=/usr/local/bin/powerpc64-unknown-freebsd13.0-as --with-ld=/usr/local/bin/powerpc64-unknown-freebsd13.0-ld --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=x86_64-unknown-freebsd13.0 Thread model: posix gcc version 9.2.0 (FreeBSD Ports Collection for powerpc64) COLLECT_GCC_OPTIONS='-gdwarf-2' '-B' '/usr/local/powerpc64-unknown-freebsd13.0/bin/' '-O2' '-pipe' '-I' '/usr/src/lib/csu/powerpc64' '-I' '/usr/src/lib/csu/common' '-I' '/usr/src/lib/libc/include' '-mlongcall' '-D' 'CRT_IRELOC_RELA' '-g' '-std=gnu99' '-Wno-format-zero-length' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' '-Wextra' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wpointer-arith' '-Wreturn-type' '-Wcast-qual' '-Wwrite-strings' '-Wswitch' '-Wshadow' '-Wunused-parameter' '-Wcast-align' '-Wchar-subscripts' '-Winline' '-Wnested-externs' '-Wredundant-decls' '-Wold-style-definition' '-Wno-pointer-sign' '-Wno-error=address' '-Wno-error=array-bounds' '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align' '-Wno-error=clobbered' '-Wno-error=deprecated-declarations' '-Wno-error=enum-compare' '-Wno-error=extra' '-Wno-error=inline' '-Wno-error=logical-not-parentheses' '-Wno-error=strict-aliasing' '-Wno-error=uninitialized' '-Wno-error=unused-but-set-variable' '-Wno- error=unused-function' '-Wno-error=unused-value' '-Wno-error=misleading-indentation' '-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value' '-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-Wno-error=bool-operation' '-Wno-error=deprecated' '-Wno-error=expansion-to-defined' '-Wno-error=format-overflow' '-Wno-error=format-truncation' '-Wno-error=implicit-fallthrough' '-Wno-error=int-in-bool-context' '-Wno-error=memset-elt-size' '-Wno-error=noexcept-type' '-Wno-error=nonnull' '-Wno-error=pointer-compare' '-Wno-error=stringop-overflow' '-Wno-error=aggressive-loop-optimizations' '-Wno-error=cast-function-type' '-Wno-error=catch-value' '-Wno-error=multistatement-macros' '-Wno-error=restrict' '-Wno-error=sizeof-pointer-memaccess' '-Wno-error=stringop-truncation' '-v' '-S' '-o' 'crt1.s' /usr/local/libexec/gcc/powerpc64-unknown-freebsd13.0/9.2.0/cc1 -quiet -v -I /usr/src/lib/csu/powerpc64 -I /usr/src/lib/csu/common -I /usr/src/lib/libc/include -isysroot /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp -D CRT_IRELOC_RELA /usr/src/lib/csu/powerpc64/crt1.c -quiet -dumpbase crt1.c -mlongcall -auxbase-strip crt1.s -gdwarf-2 -g -O2 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=deprecated-declarations -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno -error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context -Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wno-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -std=gnu99 -version -o crt1.s GNU C99
devel/freebsd-gcc9@aarch64 and devel/binutils@aarch64: locore.S vs. gcc toolchain notational mismatch (icc_sre_el2)
/usr/src/sys/arm64/arm64/locore.S: Assembler messages: /usr/src/sys/arm64/arm64/locore.S:282: Error: unknown or missing system register name at operand 2 -- `mrs x2,icc_sre_el2' /usr/src/sys/arm64/arm64/locore.S:285: Error: unknown or missing system register name at operand 1 -- `msr icc_sre_el2,x2' *** [locore.o] Error code 1 make[2]: stopped in /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG .ERROR_TARGET='locore.o' .ERROR_META_FILE='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/locore.o.meta' .MAKE.LEVEL='2' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose curdirOk=yes' _ERROR_CMD='/usr/local/bin/aarch64-unknown-freebsd13.0-gcc9 -mcpu=cortex-a53 --sysroot=/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp -B/usr/local/aarch64-unknown-freebsd13.0/bin/ -c -x assembler-with-cpp -DLOCORE -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/arm64/include -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=address -Wno-error=aggressive-loop-optimizations -Wno-error=array-bounds -Wno-error=attributes -Wno-error=cast-qual -Wno-error=enum-compare -Wno-error=inline -Wno-error=maybe-uninitialized -Wno-error=overflow -Wno-error=sequence-point -Wno-unused-but-set-variable -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-overflow -Wno-error=tautological-compare -Wno-error=stringop-overflow -Wno-error=memset-elt-size -Wno-error=packed-not-aligned -Wno-address-of-packed-member -Wno-format-zero-length -v -fno-common -fms-extensions -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fms-extensions -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/locore.S;' .CURDIR='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG' FYI: # grep -U5 icc_sre_el2 /usr/src/sys/arm64/arm64/locore.S ubfxx2, x2, #ID_AA64PFR0_GIC_SHIFT, #ID_AA64PFR0_GIC_BITS /* GIC[3:0] == 0001 - GIC CPU interface via special regs. supported */ cmp x2, #(ID_AA64PFR0_GIC_CPUIF_EN >> ID_AA64PFR0_GIC_SHIFT) b.ne2f mrs x2, icc_sre_el2 orr x2, x2, #ICC_SRE_EL2_EN /* Enable access from insecure EL1 */ orr x2, x2, #ICC_SRE_EL2_SRE/* Enable system registers */ msr icc_sre_el2, x2 2: /* Set the address to return to our return address */ msr elr_el2, x30 isb (devel/freebsd-gcc6 likely has the same status.) The context was head -r355976 based. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
buildworld for 32-bit powerpc via devel/freebsd-gcc9@powerpc (not clang): still gets the bss-plt being forced due to crtbeginS.o (build stopped)
As this avoided using system-clang (or any clang), the -secure-plt leading to bss-plt being forced issue for 32-bit powerpc appears to *NOT* be clang-specific at all! I was just curious to see what would be reported. (The system-clang and devel/binutils@powerpc combination completed buildworld buildkernel. It reported forcing bss-plt but did not stop early.) (I have left my old xtoolchain-gcc naming in directory names.) --- libc.so.7.full --- /usr/local/bin/powerpc-unknown-freebsd13.0-ld: bss-plt forced due to /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o collect2: error: ld returned 1 exit status *** [libc.so.7.full] Error code 1 For reference: # /usr/local/bin/powerpc-unknown-freebsd13.0-ld -v GNU ld (GNU Binutils) 2.33.1 For reference for the link: # Meta data file /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/lib/libc/libc.so.7.full.meta CMD @echo building shared library libc.so.7 CMD @rm -f libc.so.7 libc.so CMD /usr/local/bin/powerpc-unknown-freebsd13.0-gcc9 -gdwarf-2 --sysroot=/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp -B/usr/local/powerpc-unknown-freebsd13.0/bin/ - Wl,--secure-plt -nodefaultlibs -Wl,--version-script=Version.map-shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 `NM='/usr/local/powerpc-unkno wn-freebsd13.0/bin/nm' NMFLAGS='' lorder trivial-vdso_tc.pico . . . . . . wmemset.pico | tsort -q` -lcompiler_rt -lssp_nonshared CWD /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/lib/libc TARGET libc.so.7.full -- command output -- building shared library libc.so.7 /usr/local/bin/powerpc-unknown-freebsd13.0-ld: bss-plt forced due to /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o collect2: error: ld returned 1 exit status *** Error code 1 . . . E 36494 /usr/local/bin/powerpc-unknown-freebsd13.0-ld R 36494 /etc/libmap.conf R 36494 /var/run/ld-elf.so.hints R 36494 /lib/libc.so.7 R 36494 /usr/local/libexec/gcc/powerpc-unknown-freebsd13.0/9.2.0/liblto_plugin.so R 36494 Version.map R 36494 libc.so.7.full W 36494 libc.so.7.full R 36494 /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crti.o R 36494 /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crti.o R 36494 /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o R 36494 /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o . . . For reference for building crtbeginS.o (much gcc9 detail included from using -v): # Meta data file /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/lib/csu/powerpc/crtbeginS.o.meta CMD /usr/local/bin/powerpc-unknown-freebsd13.0-gcc9 -gdwarf-2 --sysroot=/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp -B/usr/local/powerpc-unknown-freebsd13.0/bin/ -O 2 -pipe -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -DCRT_IRELOC_SUPPRESS-g -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict- prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decl s -Wold-style-definition -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=deprecated-dec larations -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-erro r=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-error=bool-operation -Wno-error=deprecated -Wno-error=expansion-to-defined -Wno-error=format-overflow -Wno-error=format-truncation -Wno-error=implicit-fallthrough -Wno-error=int-in-bool-context - Wno-error=memset-elt-size -Wno-error=noexcept-type -Wno-error=nonnull -Wno-error=pointer-compare -Wno-error=stringop-overflow -Wno-error=aggressive-loop-optimizations -Wno-error=cast-function-type -Wn o-error=catch-value -Wno-error=multistatement-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -v -I/usr/src/lib/csu/powerpc -DSHARED -fpic -c -o crtb eginS.o /usr/src/lib/csu/common/crtbegin.c CWD /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/lib/csu/powerpc TARGET crtbeginS.o -- command output -- Using built-in specs. COLLECT_GCC=/usr/local/bin/powerpc-unknown-freebsd13.0-gcc9 Target: powerpc-
Re: New external GCC toolchain ports/packages
On 2019-Dec-18, at 13:48, John Baldwin wrote: > In the interest of supporting newer versions of GCC for a base system > toolchain, I've renamed the external GCC packages from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtoolchain package is not used for these new packages, instead > one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this > compiler to 6.5.0. > > I will leave the old ports/packages around for now to permit an easy > transition, but going forward, the -gcc6 packages should be preferred > to -xtoolchain-gcc for all but riscv (riscv64-gcc and > riscv64-xtoolchain-gcc > are separate from the powerpc64-gcc set of packages). > > In addition, I've also just added a devel/freebsd-gcc9 package which > builds -gcc9 packages. It adds powerpc and riscv flavors relative > to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > be able to finish a buildworld on any of the platforms I've tried > (amd64, mips, sparc64), but the packages should permit other developers > to get the tree building with GCC 9. To use these packages one would do > something like: > > # pkg install amd64-gcc9 > # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > You can install both the gcc6 and gcc9 versions of a package at the same > time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major > versions is similar to llvm and will also let us keep a known-good > toolchain package for older releases while using newer major versions on > newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > I do plan to switch the default toolchains for make universe/tinderbox > for targets using -xtoolchain-gcc based on GCC 6 over to the > freebsd-gcc6 variants in the next week or so. > How about base/binutils and base/gcc ? Is their (future?) status changed by any of this activity? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r355761 for amd64 self-hosted: installworld failed for: "btxld: not found" (-r35777 too, more sequencing evidence)
On 2019-Dec-14, at 19:13, Mark Millard wrote: > I give various details based on how I got past it as well > as the original error messages. > > This was a -j32 threadripper 1950X context at the start: > the installworld with -j32 got: > > --- realinstall_subdir_stand --- > btxld -v -E 0x2000 -f bin -b > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx/btx > -l boot2.ldr -o boot2.ld -P 1 boot2.bin > . . . > --- realinstall_subdir_stand --- > sh: btxld: not found > . . . > --- realinstall_subdir_stand --- > *** [boot2.ld] Error code 127 > > > However retrying without the -j32 got: > > ===> stand/i386/btx (install) > ===> stand/i386/btx/btx (install) > ===> stand/i386/btx/btxldr (install) > ===> stand/i386/btx/lib (install) > ===> stand/i386/boot2 (install) > btxld -v -E 0x2000 -f bin -b > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx/btx > -l boot2.ldr -o boot2.ld -P 1 boot2.bin > make[6]: exec(btxld) failed (No such file or directory) > *** Error code 1 > > Stop. > make[6]: stopped in /usr/src/stand/i386/boot2 > *** Error code 1 > > > Retrying the buildworld buildkernel and then the installworld, > all without -j32 and without forcing it to start from > scratch, got past the problem. > > The original -j32 buildworld buildkernel log shows: > > # grep "btxld\>" > ~/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2019-12-14:18:01:22 > | more > --- includes_subdir_usr.sbin/btxld --- > ===> usr.sbin/btxld (includes) > --- all_subdir_usr.sbin/btxld --- > ===> usr.sbin/btxld (all) > Building > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld.o > --- all_subdir_usr.sbin/btxld --- > Building > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/elfh.o > Building > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld.full > --- all_subdir_usr.sbin/btxld --- > Building > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld.debug > Building > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld > > The times in that directory show that the non-j32 build > did generate btxld and btxld.debug but the btx.full was > from the earlier -j32 build: > > # ls -laTt > /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/ > total 200 > -rw-r--r--1 root wheel715 Dec 14 18:46:16 2019 btxld.meta > -rwxr-xr-x1 root wheel 27504 Dec 14 18:46:16 2019 btxld > -rw-r--r--1 root wheel550 Dec 14 18:46:16 2019 btxld.debug.meta > -rwxr-xr-x1 root wheel 28968 Dec 14 18:46:16 2019 btxld.debug > -rwxr-xr-x1 root wheel 49568 Dec 14 18:19:13 2019 btxld.full > drwxrwxr-x2 root wheel512 Dec 14 18:18:54 2019 . > -rw-r--r--1 root wheel 3308 Dec 14 18:18:54 2019 btxld.full.meta > -rw-r--r--1 root wheel 4088 Dec 14 18:18:54 2019 elfh.o.meta > -rw-r--r--1 root wheel 4880 Dec 14 18:18:54 2019 elfh.o > -rw-r--r--1 root wheel 7371 Dec 14 18:18:54 2019 btxld.o.meta > -rw-r--r--1 root wheel 37824 Dec 14 18:18:54 2019 btxld.o > drwxrwxr-x 225 root wheel 4096 Nov 22 22:53:23 2019 .. > -rw-r--r--1 root wheel971 Nov 9 08:29:35 2018 btxld.8.gz.meta > -rw-r--r--1 root wheel 1429 Nov 9 08:29:35 2018 btxld.8.gz > > I do not know if this is some sort of race that silently > stopped btxld and btxld.debug from being generated (despite > the "Building" lines). The installworld failure happened again when I tried to update to head -r355777 . This time I'm looking at the buildworld directory content before trying the not from scratch rebuild (possibly without -j32): # ls -laTt /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/ total 200 -rwxr-xr-x1 root wheel 49568 Dec 15 12:14:30 2019 btxld.full -rw-r--r--1 root wheel754 Dec 15 12:14:03 2019 btxld.meta -rwxr-xr-x1 root wheel 27504 Dec 15 12:14:03 2019 btxld -rw-r--r--1 root wheel735 Dec 15 12:14:03 2019 btxld.debug.meta -rwxr-xr-x1 root wheel 28968 Dec 15 12:14:03 2019 btxld.debug drwxrwxr-x2 root wheel512 Dec 15 12:14:02 2019 . -rw-r--r--1 root wheel 3308 Dec 15 12:14:02 2019 btxld.full.meta -rw-r--r--1 root wheel 4088 Dec 15 12:14:02 2019 elfh.o.meta -rw-r--r--1 root wheel 4880 Dec 15 12:14:02 2019 elfh.o -rw-r--r--1 root wheel 7371 Dec 15 12:14:02 2019 btxld.o.meta -rw-r--r--1 root wheel 37824 Dec 15 12:14:02 2019 btxld.o drwxrwxr-x 225 root wheel 4096 Nov 22 22:53:23 2019 .. -rw-r--r--1 root wheel971 Nov 9 08:29:35 2018 btxld.8.gz.meta -rw-r--r--1 root wheel 1429 Nov 9 08:29:35 2018 btxld.8.gz It looks like btxld.full finished well after btxld.debug and btxld finished (despite btxld.full.meta being first). But the Start/Stop figures listed in the .meta files do not show this (I edited to align text to make comparison easier): # cd /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr
head -r355761 for amd64 self-hosted: installworld failed for: "btxld: not found"
I give various details based on how I got past it as well as the original error messages. This was a -j32 threadripper 1950X context at the start: the installworld with -j32 got: --- realinstall_subdir_stand --- btxld -v -E 0x2000 -f bin -b /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin . . . --- realinstall_subdir_stand --- sh: btxld: not found . . . --- realinstall_subdir_stand --- *** [boot2.ld] Error code 127 However retrying without the -j32 got: ===> stand/i386/btx (install) ===> stand/i386/btx/btx (install) ===> stand/i386/btx/btxldr (install) ===> stand/i386/btx/lib (install) ===> stand/i386/boot2 (install) btxld -v -E 0x2000 -f bin -b /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin make[6]: exec(btxld) failed (No such file or directory) *** Error code 1 Stop. make[6]: stopped in /usr/src/stand/i386/boot2 *** Error code 1 Retrying the buildworld buildkernel and then the installworld, all without -j32 and without forcing it to start from scratch, got past the problem. The original -j32 buildworld buildkernel log shows: # grep "btxld\>" ~/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2019-12-14:18:01:22 | more --- includes_subdir_usr.sbin/btxld --- ===> usr.sbin/btxld (includes) --- all_subdir_usr.sbin/btxld --- ===> usr.sbin/btxld (all) Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld.o --- all_subdir_usr.sbin/btxld --- Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/elfh.o Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld.full --- all_subdir_usr.sbin/btxld --- Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld.debug Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/btxld The times in that directory show that the non-j32 build did generate btxld and btxld.debug but the btx.full was from the earlier -j32 build: # ls -laTt /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/usr.sbin/btxld/ total 200 -rw-r--r--1 root wheel715 Dec 14 18:46:16 2019 btxld.meta -rwxr-xr-x1 root wheel 27504 Dec 14 18:46:16 2019 btxld -rw-r--r--1 root wheel550 Dec 14 18:46:16 2019 btxld.debug.meta -rwxr-xr-x1 root wheel 28968 Dec 14 18:46:16 2019 btxld.debug -rwxr-xr-x1 root wheel 49568 Dec 14 18:19:13 2019 btxld.full drwxrwxr-x2 root wheel512 Dec 14 18:18:54 2019 . -rw-r--r--1 root wheel 3308 Dec 14 18:18:54 2019 btxld.full.meta -rw-r--r--1 root wheel 4088 Dec 14 18:18:54 2019 elfh.o.meta -rw-r--r--1 root wheel 4880 Dec 14 18:18:54 2019 elfh.o -rw-r--r--1 root wheel 7371 Dec 14 18:18:54 2019 btxld.o.meta -rw-r--r--1 root wheel 37824 Dec 14 18:18:54 2019 btxld.o drwxrwxr-x 225 root wheel 4096 Nov 22 22:53:23 2019 .. -rw-r--r--1 root wheel971 Nov 9 08:29:35 2018 btxld.8.gz.meta -rw-r--r--1 root wheel 1429 Nov 9 08:29:35 2018 btxld.8.gz I do not know if this is some sort of race that silently stopped btxld and btxld.debug from being generated (despite the "Building" lines). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head src.conf loses almost all references to powerpc in -r353933 (and later)
/base/head/share/man/man5/src.conf.5 : -r353933 show 10 matches to "power" (case independent). -r353358 shows 244 matches to "power" (case independent). In head -r355644 I got the following: # man src.conf | grep -i power Set to not build LLVM target support for PowerPC. The Set to build LLVM target support for PowerPC. The Set to force the powerpc boot loader to launch the kernel in So all of 3 lines and 3 references. This is what got me to look at /base/head/share/man/man5/src.conf.5 . For reference: Revision 353933 - (view) (download) (annotate) - [select for diffs] Modified Wed Oct 23 16:48:17 2019 UTC (7 weeks ago) by dim File length: 55546 byte(s) Diff to previous 353358 Slightly expand description of WITH_SHARED_TOOLCHAIN, add a corresponding WITHOUT_SHARED_TOOLCHAIN description, and regenerate src.conf(5). MFC after: 3 days Revision 353358 - (view) (download) (annotate) - [select for diffs] Modified Wed Oct 9 17:06:56 2019 UTC (2 months ago) by dim File length: 57289 byte(s) Diff to previous 352928 Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316 . Release notes for llvm, clang, lld and libc++ 9.0.0 are available here: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r355027 cross build for powerpc64 (system-clang-9 and devel/binutils@powerpc64 based) linker fails: undefined reference to lldb_private::formatters::CMTimeSummaryProvider
On 2019-Nov-23, at 04:14, Mark Millard wrote: > This is an ELFv1 context, not ELFv2, despite the system-clang-9 basis. > > --- lldb.full --- > /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/liblldb/liblldb.a(ObjCLanguage.o):(.toc+0x8): > undefined reference to > `lldb_private::formatters::CMTimeSummaryProvider(lldb_private::ValueObject&, > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)' > > . . . > > --- all_subdir_kerberos5 --- > Building > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/kerberos5/libexec/hpropd/hpropd.full > --- all_subdir_usr.bin --- > --- all_subdir_usr.bin/clang/lldb --- > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** [lldb.full] Error code 1 > > make[5]: stopped in /usr/src/usr.bin/clang/lldb > .ERROR_TARGET='lldb.full' > .ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/lldb/lldb.full.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='c++ -target powerpc64-unknown-freebsd13.0 > --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe > -I/usr/src/contrib/llvm/tools/lldb/include > -I/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/lldb > -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT > -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -D__STDC_CONSTANT_MACROS > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC > -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd13.0\" > -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" > -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV > -DLLVM_NATIVE_ASMPARSER=LLVMInitializePowerPCAsmParser > -DLLVM_NATIVE_ASMPRINTER=LLVMInitializePowerPCAsmPrinter > -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializePowerPCDisassembler > -DLLVM_NATIVE_TARG ET=LLVMInitializePowerPCTarget -DLLVM_NATIVE_TARGETINFO=LLVMInitializePowerPCTargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializePowerPCTargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-format-zero-length -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -o lldb.full Driver.o /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/liblldb/liblldb.a /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/libclang/libclang.a /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerp c64/lib/clang/libllvm/libllvm.a -ledit -lexecinfo -lpanel -lncursesw -lz -lpthread ;' > .CURDIR='/usr/src/usr.bin/clang/lldb' > .MAKE='make' > .OBJDIR='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/lldb' > .TARGETS='all' > DESTDIR='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp' > LD_LIBRARY_PATH='' > MACHINE='powerpc' > MACHINE_ARCH='powerpc64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20181221' > PATH='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64' > .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk > /usr/src/share/mk/src.sys.env.mk > /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host > /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk > /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk > /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk > /usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/clang/lldb/Makefile > /usr/src/lib/clang/lldb.pre.mk /usr/src/lib/clang/clang.pre.mk > /usr
Re: head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h
[In part this note shows that the issue is not specific to
cross builds: -a arm64.aarch64 is not essential. But it
also shows just where the /sys/param.h comes from.]
On 2019-Nov-24, at 15:22, Mark Millard wrote:
> On 2019-Nov-24, at 15:11, Ben Woods wrote:
>
>> On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote:
>> My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
>> all getting:
>>
>> awk: can't open file /sys/param.h
>> source line number 1
>>
>> Hi Mark,
>>
>> I have been getting this same error on amd64 for some time when I use the
>> command below.
>> # poudriere jail -j 13amd64 -u -m src=/usr/src
>>
>> Any ideas what it could be?
>
> Not so far. Good to know that cross-building is not part of the required
> context.
>
> I've yet to find a place that might be involved that mixes awk use with an
> expression
> generating a file path that could generate /sys/param.h as the path.
>
> If this was happening in my prior -r352341 context, I did not notice it. I
> jumped
> from there to -r355027 . So I can not effectively narrow the range for when it
> started based on my activity.
I've got evidence of what is reporting the /sys/param.h path:
+ [ -n '' ]
+ return 0
+ build_native_xtools
+ [ 0 -eq 1 ]
+ return 0
+ awk '/^\#define[[:blank:]]__FreeBSD_version/ {print $3}'
/usr/local/poudriere/jails/testBugzilla215561/usr/include/sys/param.h
+ setvar version_extra 1300061
+ [ -r /usr/src/sys/conf/newvers.sh ]
+ update_version 1300061
+ local 'version_extra=1300061'
+ grep '^[RB][A-Z]*=' /usr/src/sys/conf/newvers.sh
+ eval 'REVISION="13.0"' 'BRANCH=${BRANCH_OVERRIDE:-CURRENT}'
'RELEASE="${REVISION}-${BRANCH}"' 'RELDATE=$(awk'
$'\'/__FreeBSD_version.*propagated' to newvers/ {print $'$3}\''
'${PARAMFILE:-${SYSDIR}/sys/param.h})'
+ awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' /sys/param.h
awk: can't open file /sys/param.h
source line number 1
So it appears that:
${PARAMFILE:-${SYSDIR}/sys/param.h}
became just:
/sys/param.h
suggesting that both PARAMFILE aned SYSDIR were empty/undefined.
But looking around shows that SYSDIR being empty/undefined can
lead to PARAMFILE being /sys/param.h directly.
A grep shows for PARAMFILE :
/usr/src/include/Makefile: env NEWVERS_SH=${NEWVERS_SH}
PARAMFILE=${PARAM_H} SYSDIR=${SYSDIR} \
/usr/src/sys/conf/newvers.sh:RELDATE=$(awk '/__FreeBSD_version.*propagated to
newvers/ {print $3}' ${PARAMFILE:-${SYSDIR}/sys/param.h})
and for PARAM_H :
/usr/src/include/Makefile:PARAM_H= ${SYSDIR}/sys/param.h
/usr/src/include/Makefile:osreldate.h: ${NEWVERS_SH} ${PARAM_H}
${MK_OSRELDATE_SH}
/usr/src/include/Makefile: env NEWVERS_SH=${NEWVERS_SH}
PARAMFILE=${PARAM_H} SYSDIR=${SYSDIR} \
I got the message for the above from doing:
poudriere -x jail -c -m src=/usr/src -J 32 -v head@355027 -j testBugzilla215561
(with an appropriate env MAKEOBJDIRPREFIX=. . . for my
environment). This was as part of seeing if an old
bugzilla report can be closed. (It can be.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
On 2019-Nov-19, at 20:14, Mark Millard via freebsd-ppc wrote:
> On 2019-Nov-19, at 19:58, Mark Linimon wrote:
>
>>> devel/freebsd-gcc6
>>> devel/freebsd-gcc6@aarch64
>>
>> These two ports are exactly equivalent.
>>
>> I did not have enough time before the commit to puzzle out a way to
>> work around that. I have limited understanding of flavors.
>>
>> The way it *should* work IMHO is for the former to refuse to build
>> with a message like "is a meta port -- nothing to build." This is
>> used in several other existing masterports.
>>
>
> Ahh. That helps explain the use of "native" in devel/binutils and
> why it is listed first and that there is a matching default, from
> looking . . .
>
> FLAVORS=native aarch64 aarch64_none_elf amd64 arm_gnueabi
> arm_none_eabi \
>avr i386 mingw32 mips mips64 powerpc64 riscv64 s390x sparc64
> FLAVOR?=native
>
> Looks like that makes testing for the default (or literal native here)
> testable:
>
> .if ${FLAVOR} != native
>
> So adding an extra flavor as a default could allow for generating an error?
>
> Thanks for the note. It helped me understand what to expect and what to watch
> out for.
>
Hmm. On an aarch64 machine I could not use:
pkg install freebsd-gcc6@aarch64
after my poudriere bulk run. I had to use:
pkg install freebsd-gcc6
So there are places where the two notations are not equivalent,
despite aarch64 being listed first for freebsd-gcc6's FLAVORS.
One has to know what the FLAVORS list starts with in order to
know what to type in some contexts; one can not just always
type in the @flavor notation.
This was for:
# pkg -v
1.12.0
It reported:
# pkg install devel/freebsd-gcc6@aarch64
Updating custom repository catalogue...
custom repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'devel/freebsd-gcc6@aarch64'
have been found in the repositories
The file for the poudriere bulk -f listed:
devel/freebsd-gcc6@aarch64
(despite the context being aarch64 in the first place).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h
On 2019-Nov-24, at 15:11, Ben Woods wrote: > On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote: > My poudiere jail constructions with the likes of -a arm64.aarch64 -x are > all getting: > > awk: can't open file /sys/param.h > source line number 1 > > Hi Mark, > > I have been getting this same error on amd64 for some time when I use the > command below. > # poudriere jail -j 13amd64 -u -m src=/usr/src > > Any ideas what it could be? Not so far. Good to know that cross-building is not part of the required context. I've yet to find a place that might be involved that mixes awk use with an expression generating a file path that could generate /sys/param.h as the path. If this was happening in my prior -r352341 context, I did not notice it. I jumped from there to -r355027 . So I can not effectively narrow the range for when it started based on my activity. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h
My poudiere jail constructions with the likes of -a arm64.aarch64 -x are all getting: awk: can't open file /sys/param.h source line number 1 If /sys is supposed to be something like: # ls -ld /sys lrwxr-xr-x 1 root wheel 11 May 21 2018 /sys -> usr/src/sys then the path would appear to need to be something like /sys/sys/param.h . But I notice that the likes of my: /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud/ does not have a sys/ . Possibly (likely?) not relevant: I'll note that doing a source upgrade to go from head -r352341 to -r355027 did not establish a /etc/os-release on the amd64 host. But /var/run/os-release does exist. By contrast: # ls -ld /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud/etc/os-release lrwxr-xr-x 1 root wheel 21 Nov 23 19:56 /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud/etc/os-release -> ../var/run/os-release was established, possibly via the distrib-dirs distribution DB_FROM_SRC=1 use involved in (re-)constructing /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud/ . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: head -r355027 cross build for 32-bit powerpc (system-clang-9 and devel/binutils@powerpc64 based): lots of 'bss-plt forced due to'
On 2019-Nov-23, at 04:56, Mark Millard wrote: > The clang code generation and secure-plt handling and binutils ld handling > do not match (ELFv1 anyway) but the modern ld no longer seems to exit with > an error code for this context so none of the below stopped the build. (I've > no clue if the built materials are operable on the old PowerMacs or not --and > might not know for some time.) > > # grep bss-plt > /root/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_altbinutils-amd64-host-2019-11-23:04:38:28 > | more > /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to > dummynet.kld > /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to > geom_cache.kld > /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to > ip_mroute.kld > . . . I should have also listed examples of the crt1.o related messages: # grep bss-plt /root/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_altbinutils-amd64-host-2019-11-23:03:22:16 | more /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crt1.o /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crt1.o /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crt1.o . . . (lots of crt1.o references) . . . /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to accf_http.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to acl_nfs4.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to acl_posix1e.kld . . . (I had to adjust one of my old debugging changes and restart the build between the two logs. I originally only searched the 2nd log.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r355027 cross build for 32-bit powerpc (system-clang-9 and devel/binutils@powerpc64 based): lots of 'bss-plt forced due to'
The clang code generation and secure-plt handling and binutils ld handling do not match (ELFv1 anyway) but the modern ld no longer seems to exit with an error code for this context so none of the below stopped the build. (I've no clue if the built materials are operable on the old PowerMacs or not --and might not know for some time.) # grep bss-plt /root/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_altbinutils-amd64-host-2019-11-23:04:38:28 | more /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to dummynet.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to geom_cache.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ip_mroute.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ipfw_nptv6.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to hwpmc.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to iflib.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ispfw.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to dtrace.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ig4.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atajmicron.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_1040.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to gpiopps.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to if_fwe.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to h_ertt.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_1080.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to fusefs.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to geom_concat.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atamarvell.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to dtrace_test.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to kbdmux.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_12160.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ichsmb.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ktls_ocf.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ksyms.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atamicron.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_2100.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to profile.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atanational.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_2200.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to iscsi.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to intpm.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to if_jme.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to if_fwip.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to prototype.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atanetcell.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to if_lge.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_2300.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ismt.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to kgssapi_krb5.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atanvidia.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to sdt.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to libmchain.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to if_le.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_2322.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to lindebugfs.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to libiconv.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to nfsmb.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to iscsi_initiator.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to lpt.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to isp_2400.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to atapromise.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ext2fs.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to if_cxgb.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced
head -r355027 cross build for powerpc64 (system-clang-9 and devel/binutils@powerpc64 based) linker fails: undefined reference to lldb_private::formatters::CMTimeSummaryProvider
This is an ELFv1 context, not ELFv2, despite the system-clang-9 basis. --- lldb.full --- /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/liblldb/liblldb.a(ObjCLanguage.o):(.toc+0x8): undefined reference to `lldb_private::formatters::CMTimeSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)' . . . --- all_subdir_kerberos5 --- Building /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/kerberos5/libexec/hpropd/hpropd.full --- all_subdir_usr.bin --- --- all_subdir_usr.bin/clang/lldb --- c++: error: linker command failed with exit code 1 (use -v to see invocation) *** [lldb.full] Error code 1 make[5]: stopped in /usr/src/usr.bin/clang/lldb .ERROR_TARGET='lldb.full' .ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/lldb/lldb.full.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='c++ -target powerpc64-unknown-freebsd13.0 --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe -I/usr/src/contrib/llvm/tools/lldb/include -I/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/lldb -I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV -DLLVM_NATIVE_ASMPARSER=LLVMInitializePowerPCAsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializePowerPCAsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializePowerPCDisassembler -DLLVM_NATIVE_TARGET =LLVMInitializePowerPCTarget -DLLVM_NATIVE_TARGETINFO=LLVMInitializePowerPCTargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializePowerPCTargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-format-zero-length -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -o lldb.full Driver.o /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/liblldb/liblldb.a /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/libclang/libclang.a /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc6 4/lib/clang/libllvm/libllvm.a -ledit -lexecinfo -lpanel -lncursesw -lz -lpthread ;' .CURDIR='/usr/src/usr.bin/clang/lldb' .MAKE='make' .OBJDIR='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/usr.bin/clang/lldb' .TARGETS='all' DESTDIR='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp' LD_LIBRARY_PATH='' MACHINE='powerpc' MACHINE_ARCH='powerpc64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/clang/lldb/Makefile /usr/src/lib/clang/lldb.pre.mk /usr/src/lib/clang/clang.pre.mk /usr/src/lib/clang/llvm.pre.mk /usr/src/lib/clang/clang.build.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.m
Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
On 2019-Nov-19, at 19:58, Mark Linimon wrote:
>> devel/freebsd-gcc6
>> devel/freebsd-gcc6@aarch64
>
> These two ports are exactly equivalent.
>
> I did not have enough time before the commit to puzzle out a way to
> work around that. I have limited understanding of flavors.
>
> The way it *should* work IMHO is for the former to refuse to build
> with a message like "is a meta port -- nothing to build." This is
> used in several other existing masterports.
>
Ahh. That helps explain the use of "native" in devel/binutils and
why it is listed first and that there is a matching default, from
looking . . .
FLAVORS=native aarch64 aarch64_none_elf amd64 arm_gnueabi arm_none_eabi
\
avr i386 mingw32 mips mips64 powerpc64 riscv64 s390x sparc64
FLAVOR?=native
Looks like that makes testing for the default (or literal native here) testable:
.if ${FLAVOR} != native
So adding an extra flavor as a default could allow for generating an error?
Thanks for the note. It helped me understand what to expect and what to watch
out for.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
On 2019-Nov-19, at 11:19, John Baldwin wrote: > On 11/19/19 10:34 AM, Mark Millard wrote: >> [A similar question to the below exists for base/gcc . The lang/gcc* are >> being ELFv2 enabled for powerpc64 by checking the environment for if it is >> new enough and already is ELFv2 based.] >> >> Begin forwarded message: >> >> From: bugzilla-nore...@freebsd.org >> Subject: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and >> lang/gcc8-devel to ELFv2 ABI on powerpc64 >> Date: November 19, 2019 at 09:32:52 PST >> To: marklmi26-f...@yahoo.com >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239813 >> >> Gerald Pfeifer changed: >> >> What|Removed |Added >> >> Summary|Update lang/gcc8 and|Update lang/gcc9, >> |lang/gcc9 to ELFv2 ABI on |lang/gcc9-devel, lang/gcc8, >> |powerpc64 |and lang/gcc8-devel to >> ||ELFv2 ABI on powerpc64 >> >> --- Comment #38 from Gerald Pfeifer --- >> (In reply to Mark Millard from comment #35) >>> I do not know the intent for devel/powerpc64-gcc relative >>> to future ELFv2 ABI use. Does it need anything? (May be >>> it is updating to gcc9 or some such first?) >> >> Updating to GCC 9 would be my recomendation, though I have no >> involvement with that port. >> >> lang/gcc9-devel should be fine now, both wrt. the new ABI as well >> as building with clang. >> >> Next I'll make the remaining equivalent changes to lang/gcc9 and >> lang/gcc8-devel. > > I've just committed a new devel/freebsd-gcc6 port (with flavors) to replace > the powerp64-gcc port (and slaves) with an intention of creating a > freebsd-gcc9 port as a followup. It seems once freebsd-gcc9 exists we can > apply this change to that. > > base/gcc will also similarly be adjusted to base/gcc6 and base/gcc9 in the > future. > > The reason to keep old versions is that gcc6 is known to work (for some value > of work) for existing releases, so we want to provide different packages for > different major compiler versions to cope with newer OS releases supporting > newer compilers (e.g. we will patch head to work with freebsd-gcc9, but if > we only had a single powerpc64-gcc port we wouldn't be able to provide a > working compiler for stable/11 if we changed powerpc64-gcc to GCC 9). > Cool. I'll adjust my src.conf variations to match the new naming. Just some FYI notes: The old devel/*-gcc ports may need CONLFICTS assignment as well (until they are removed). In an amd64 context I tried poudriere bulk based on including (as a test): devel/freebsd-gcc6 devel/freebsd-gcc6@aarch64 devel/freebsd-gcc6@amd64 devel/freebsd-gcc6@powerpc64 and it got: [00:00:43] [04] [00:00:00] Building devel/freebsd-gcc6@aarch64 | aarch64-gcc6-6.4.0 [00:00:43] [05] [00:00:00] Building devel/freebsd-gcc6@amd64 | amd64-gcc6-6.4.0 [00:00:43] [06] [00:00:00] Building devel/freebsd-gcc6@powerpc64 | powerpc64-gcc6-6.4.0 . . . [00:05:02] [04] [00:04:19] Finished devel/freebsd-gcc6@aarch64 | aarch64-gcc6-6.4.0: Success . . . [00:07:25] [06] [00:06:42] Finished devel/freebsd-gcc6@powerpc64 | powerpc64-gcc6-6.4.0: Success [00:07:51] [05] [00:07:08] Finished devel/freebsd-gcc6@amd64 | amd64-gcc6-6.4.0: Success . . . [00:34:08] Built ports: . . . devel/freebsd-gcc6 . . . devel/freebsd-gcc6@powerpc64 devel/freebsd-gcc6@amd64 . . . The "Built ports" apparently choose to drop the @aarch64 notation and the devel/freebsd-gcc6 was not rejected but had nothing directly built for it. (I've not used flavors all that much so I was curious.) In part I tried devel/freebsd-gcc6 (no explicit flavor) because, as I remember, devel/binutils without an explicit flavor does @native that is distinct from the @(same-as-host) flavor, just like building devel/amd64-binutils in an amd64 environment was distinct from building devel/binutils in that same environment. Or that seemed to be the intent for devel/binutils . === I started a buildworld buildkernel experiment, targeting aarch64 uisng the ddevel/freebsd-gcc6@aarch materials. It seemed to generally work, as far as it got. The below may well have been true if I had tried to the xtoolchain materials instead and may well be far from new. (I've rarely done gcc based aarch64 targeting and do not remember for sure if this resulted before or not.) The build has -v for the gcc6/g++6 commands and so shows more context than usual. --- locore.o --- /usr/src/sys/arm64/arm64/locore.S: Assembler messages: /usr/src/sys/arm64/arm64/locore.S:251: Error: unknown or missing system register name at operand 2 -- `mrs x2,icc_sre_el2' /usr/src/sys/arm64/arm64/locore.S:254: Error: unknown or missing system register name at operand 1 -- `msr icc_sre_el2,x2' The recorded commands were: # Meta data file /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/sys/G
Fwd: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64
[A similar question to the below exists for base/gcc . The lang/gcc* are being ELFv2 enabled for powerpc64 by checking the environment for if it is new enough and already is ELFv2 based.] Begin forwarded message: From: bugzilla-nore...@freebsd.org Subject: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64 Date: November 19, 2019 at 09:32:52 PST To: marklmi26-f...@yahoo.com https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239813 Gerald Pfeifer changed: What|Removed |Added Summary|Update lang/gcc8 and|Update lang/gcc9, |lang/gcc9 to ELFv2 ABI on |lang/gcc9-devel, lang/gcc8, |powerpc64 |and lang/gcc8-devel to ||ELFv2 ABI on powerpc64 --- Comment #38 from Gerald Pfeifer --- (In reply to Mark Millard from comment #35) > I do not know the intent for devel/powerpc64-gcc relative > to future ELFv2 ABI use. Does it need anything? (May be > it is updating to gcc9 or some such first?) Updating to GCC 9 would be my recomendation, though I have no involvement with that port. lang/gcc9-devel should be fine now, both wrt. the new ABI as well as building with clang. Next I'll make the remaining equivalent changes to lang/gcc9 and lang/gcc8-devel. -- You are receiving this mail because: You are on the CC list for the bug. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r511878 - in head/devel: llvm90 llvm90/files/openmp xtoolchain-llvm-devel xtoolchain-llvm90: pkg-static: Unable to access file /wrkdirs/usr/. . ./llvm90/bin/ld:No such file or director
On 2019-Sep-19, at 00:33, Li-Wen Hsu wrote: > On Thu, Sep 19, 2019 at 8:29 AM Mark Millard via freebsd-toolchain > wrote: >> >> [This is from a system-clang 8 based FreeBSD context for >> powerpc64 [ELFv1], not the usual gcc 4.2.1 based context.] >> >> In attempting to update the ports I normally build, jumping >> ahead from -r509171 to ports head -r512281, I got the >> following in the poudriere-devel bulk build: >> >> . . . >> === >> ===> Building package for xtoolchain-llvm90-0.2 >> pkg-static: Unable to access file >> /wrkdirs/usr/ports/devel/xtoolchain-llvm90/work/stage/usr/local/llvm90/bin/ld:No >> such file or directory >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports/devel/xtoolchain-llvm90 >> =>> Cleaning up wrkdir >> ===> Cleaning for xtoolchain-llvm90-0.2 >> build of devel/xtoolchain-llvm90 | xtoolchain-llvm90-0.2 ended at Wed Sep 18 >> 20:08:59 PDT 2019 >> build time: 00:01:42 >> !!! build failure encountered !!! > > (CC list adjusted) > > Here is the patch hopefully can fix this: https://reviews.freebsd.org/D21680 > That let my build work. Thanks. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r511878 - in head/devel: llvm90 llvm90/files/openmp xtoolchain-llvm-devel xtoolchain-llvm90: pkg-static: Unable to access file /wrkdirs/usr/. . ./llvm90/bin/ld:No such file or directo
[This is from a system-clang 8 based FreeBSD context for powerpc64 [ELFv1], not the usual gcc 4.2.1 based context.] In attempting to update the ports I normally build, jumping ahead from -r509171 to ports head -r512281, I got the following in the poudriere-devel bulk build: . . . === ===> Building package for xtoolchain-llvm90-0.2 pkg-static: Unable to access file /wrkdirs/usr/ports/devel/xtoolchain-llvm90/work/stage/usr/local/llvm90/bin/ld:No such file or directory *** Error code 1 Stop. make: stopped in /usr/ports/devel/xtoolchain-llvm90 =>> Cleaning up wrkdir ===> Cleaning for xtoolchain-llvm90-0.2 build of devel/xtoolchain-llvm90 | xtoolchain-llvm90-0.2 ended at Wed Sep 18 20:08:59 PDT 2019 build time: 00:01:42 !!! build failure encountered !!! === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: runnning after linking without -Wl,-rpath=/usr/local/lib/gcc9 : ld-elf.so.1: . . . : Undefined symbol "__floatunditf@GCC_4.2.0" (possibly arm specific)
On 2019-Sep-6, at 23:29, Mark Millard wrote: > When I built a fairly simple C++17 program (not FreeBSD specific) > (targeting aarch64) with g++9 and then tried to run it, running > reported (I omit a very long file path/name that I was using): > > ld-elf.so.1: . . . : Undefined symbol "__floatunditf@GCC_4.2.0" > > # ldd . . . > . . .: > libstdc++.so.6 => /usr/local/lib/gcc9/libstdc++.so.6 (0x404dc000) > libm.so.5 => /lib/libm.so.5 (0x406d4000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40745000) > libthr.so.3 => /lib/libthr.so.3 (0x40786000) > libc.so.7 => /lib/libc.so.7 (0x407e2000) > > Using -Wl,-rpath=/usr/local/lib/gcc9 in the link avoided the > problem and let the program run (by changing which library > is used, for at least one library). > > I've not checked if this is aarch64 specific or FreeBSD vintage > specific or g++ vintage specific. (The context is head -r350364 .) powerpc64 did not require the -Wl,-rpath=/usr/local/lib/gcc9 So some architectures do not have the problem. > (The program and its source are not ready for any distribution.) When attempting to use g++9 with the system libc++ instead of libstdc++ on aarch64 I got it to work by making it use: # ldd . . . . . .: libc++.so.1 => /usr/lib/libc++.so.1 (0x404e2000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x405d5000) libthr.so.3 => /lib/libthr.so.3 (0x4061a000) libm.so.5 => /lib/libm.so.5 (0x40676000) libc.so.7 => /lib/libc.so.7 (0x406e7000) libgcc_s.so.1 => /usr/local/lib/gcc9/libgcc_s.so.1 (0x40abe000) In other words: make it avoid use of: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40abe000) in order to pick up a definition of __floatunditf@GCC_4.2.0 . But the odd mix is probably not a generally good idea. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
runnning after linking without -Wl,-rpath=/usr/local/lib/gcc9 : ld-elf.so.1: . . . : Undefined symbol "__floatunditf@GCC_4.2.0"
When I built a fairly simple C++17 program (not FreeBSD specific) (targeting aarch64) with g++9 and then tried to run it, running reported (I omit a very long file path/name that I was using): ld-elf.so.1: . . . : Undefined symbol "__floatunditf@GCC_4.2.0" # ldd . . . . . .: libstdc++.so.6 => /usr/local/lib/gcc9/libstdc++.so.6 (0x404dc000) libm.so.5 => /lib/libm.so.5 (0x406d4000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40745000) libthr.so.3 => /lib/libthr.so.3 (0x40786000) libc.so.7 => /lib/libc.so.7 (0x407e2000) Using -Wl,-rpath=/usr/local/lib/gcc9 in the link avoided the problem and let the program run (by changing which library is used, for at least one library). I've not checked if this is aarch64 specific or FreeBSD vintage specific or g++ vintage specific. (The context is head -r350364 .) (The program and its source are not ready for any distribution.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: linker not using make.conf
On 2019-Sep-4, at 11:35, Sid wrote:
> When the base linker is not available, the link needs to be from /usr/bin/ld
> rather than from /usr/local/*/ to /usr/local/bin/ld.lld80 or variant of that.
> Also, programs being compiled do look for /usr/bin/ld or maybe another ld
> under /usr/local/*. There were about two locations that could be used for
> each version of the compiler and its toolchain, one like you described,
> because another also had a soft link.
>
> Mine works, since I have a soft link from /usr/bin/ld to the needed one in
> /usr/local/bin/*
>
> If I remember correctly, installing xtoolchain-llvm didn't do much, except
> for give hints on what to put as XLD. From trial an error, I found that, LD
> covers everything, including what XLD covers, except when XLD is used, it
> overrides LD only for ports. In other words, LD in make.conf covered building
> the kernel, base, and ports. When XLD was set, it overrode LD's settings only
> for ports. At least the X version (XCC, XCXX, compared to CC, CXX) of the
> other make.conf setting.
>
> The point is, I wonder how much confusion is being caused for developers,
> when LD and XLD are not working as they are supposed to. When one gets fixed,
> but ends up with the same problem, because the base linker is used, rather
> than the one make.conf is intended to make work. I wonder if this has to do
> with why some ports require llvm80, and others llvm60, when the assumption is
> on the wrong needed update, when it's not using the linkers from those. I
> also guess that, this is causing difficulties for when trying to make clang's
> utils work for different architectures. A problem like this doesn't help, and
> it likely slows down development, that a new release must be waited for
> before significant improvements can be made. The LD setting in make.conf not
> working properly is a fundamental problem, that can cause other problems, and
> false assumptions.
>
> It's more difficult to see the problem, if the base ld is available.
>
>
>> Sent: Wednesday, September 04, 2019 at 10:18 AM
>> From:
>> Cc: freebsd-toolchain@freebsd.org
>> Subject: Re: linker not using make.conf
>
>> The LD variable only effects the very few cases where the linker is called
>> directly. The linker is almost always run via clang. If you install the
>> xtoolchain-llvm80 port it will install a link from
>> /usr/local/llvm80/bin/ld.lld to /usr/local/llvm80/bin/ld which I think will
>> be sufficient for your use case.
>>
>> On Tue, Sep 03, 2019 at 11:04:08PM +0200, Sid wrote:
>>> In /etc/make.conf, I have
>>> LD= /usr/local/bin/ld.lld80
>>>
>>> This is not used for ports. It may be used for building the kernel and
>>> world.
>>>
>>> clang-8: error: unable to execute command: Executable "ld" doesn't exist!
>>> clang-8: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>> *** Error code 1
>>>
>>> XLD= /usr/local/bin/ld.lld80 being set as well also provides the same
>>> error. XD sets it for all, but XLD is only applicable if a different
>>> compiler is used for ports than kernel and the base. When LD is set, XLD
>>> only applies when it is set as well, but this suggests that XLD is not
>>> working correctly either.
>>>
>>> I have to manually link /usr/bin/ld to /usr/local/bin/ld.lld80 for ports to
>>> build correctly. This is with both make, and with portmaster.
>>>
>>> I built my computer without ld in the base system, and this has worked
>>> well. make.conf should reference the chosen linker without having to
>>> manually link it. Otherwise, LD in make.conf is not working correctly, and
>>> gives the impression that one linker is used, when it's not. This can cause
>>> faulty conclusions and confusion for developers as well, who think one
>>> linker is set, when it's not.
May be what brooks was referring to is not familiar.
So I show examples for system-clang++, llvm90's
clang++90, and g++9.
Here is an example of building and linking a program:
# c++ -std=c++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# c++ -std=c++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# c++ -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o cpp_clockinfo.o
-o cpp_clockinfo_main cpp_clockinfo_main.cpp
That last runs a linker aa part of its activity.
It make s no use of makefile macros or environment variables LD or XLD.
This would be true even if if comamnds were in a makefile.
Use of the -### option for the last of those commands shows the link
command that clang used ("/usr/bin/ld"):
FBSDFHUGE# c++ -### -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM
8.0.1)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/c++" "-cc1" "-triple" "x86_64-unknown-freebsd13.0" "-emit-obj"
"-disable-free" "-main-file-name" "cpp_clockinfo_main.cpp"
FreeBSD-head-amd64-gcc builds are broken since 2019-Aug-17 or so: no previous declaration for '__ashldi3' (stand/i386/boot2 context)
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/11176/console is for -r351411 and shows: 15:43:33 --- ashldi3.o --- 15:43:33 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc --sysroot=/tmp/obj/workspace/src/amd64.amd64/tmp -B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe -I/workspace/src/stand/i386/btx/lib -nostdinc -I/tmp/obj/workspace/src/amd64.amd64/stand/libsa32 -I/workspace/src/stand/libsa -D_STANDALONE -I/workspace/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT -I/workspace/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -m32 -ffreestanding -mno-mmx -mno-sse -msoft-float -march=i386 -I. -fomit-frame-pointer -mrtd -mregparm=3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/workspace/src/stand/common -Wall -Waggregate-return -Wbad-function-cast -Wno-cast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline -g -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Werror -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=att ributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Os -mpreferred-stack-boundary=2 -Os -fno-asynchronous-unwind-tables --param max-inline-insns-single=100 -Wno-missing-prototypes -c /workspace/src/contrib/compiler-rt/lib/builtins/ashldi3.c -o ashldi3.o 15:43:33 /workspace/src/contrib/compiler-rt/lib/builtins/ashldi3.c:22:1: error: no previous declaration for '__ashldi3' [-Werror=missing-declarations] 15:43:33 __ashldi3(di_int a, si_int b) 15:43:33 ^ 15:43:33 --- all_subdir_kerberos5 --- . . . 15:43:33 --- all_subdir_stand --- 15:43:33 *** [ashldi3.o] Error code 1 15:43:33 15:43:33 make[5]: stopped in /workspace/src/stand/i386/boot2 15:43:33 1 error This error first showed back at: https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/11080/ which is for -r351138 . The prior build was for -r351133 and it built okay. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r351178 amd64->powerpc (32-bit) cross build using devel/xtoolchain-llvm90: "ld: error: symbol '_ThreadRuneLocale' has no type"
I decided to see what would happen if I tried a
32-bit powerpc buildworld buildkernel (cross
build) based on using devel/llvm90 (after the rc2
update). Where and how it stopped is shown below.
(Note the reference to clang-9 as well.)
--- all_subdir_usr.bin ---
--- apply.full ---
ld: error: symbol '_ThreadRuneLocale' has no type
>>> defined in
>>> /usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/lib/libc.so.7
>>> referenced by _ctype.h:0
>>> (/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/include/_ctype.h:0)
>>> apply.o:(main)
ld: error: symbol '_ThreadRuneLocale' has no type
>>> defined in
>>> /usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/lib/libc.so.7
>>> referenced by runetype.h:98
>>> (/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/include/runetype.h:98)
>>> apply.o:(main)
--- all_subdir_lib ---
. . .
--- all_subdir_usr.bin ---
clang-9: error: linker command failed with exit code 1 (use -v to see
invocation)
--- all_subdir_bin ---
. . .
--- all_subdir_usr.bin ---
*** [apply.full] Error code 1
make[4]: stopped in /usr/src/usr.bin/apply
.ERROR_TARGET='apply.full'
.ERROR_META_FILE='/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/usr.bin/apply/apply.full.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='/usr/local/bin/clang90 -target powerpc-unknown-freebsd13.0
--sysroot=/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp
-B/var/empty -O2 -pipe -g -std=gnu99 -Wno-format-zero-length
-fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -Wl,--secure-plt -Wl,--no-threads -o apply.full apply.o
-lsbuf ;'
.CURDIR='/usr/src/usr.bin/apply'
.MAKE='make'
.OBJDIR='/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/usr.bin/apply'
.TARGETS='all'
DESTDIR='/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp'
LD_LIBRARY_PATH=''
MACHINE='powerpc'
MACHINE_ARCH='powerpc'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/sbin:/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/bin:/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/sbin:/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/bin:/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/powerpcvtsc-xtoolchain-llvm/powerpc.powerpc/usr/src/powerpc.powerpc'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk
/usr/src/share/mk/src.sys.env.mk
/root/src.configs/src.conf.powerpc-xtoolchain-llvm.amd64-host
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk
/root/src.configs/make.conf /usr/src/share/mk/local.sys.mk
/usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/apply/Makefile
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk
/usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk
/usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk
/usr/src/usr.bin/apply/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.nls.mk
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr
/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/usr.bin/apply'
1 error
This was based on:
# more ~/src.configs/src.conf.powerpc-xtoolchain-llvm.amd64-host
TO_TYPE=powerpc
LLVM_VINTAGE=llvm90
#
KERNCONF=GENERICvtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
WITHOUT_SYSTEM_LINKER=
#
WITH_LLVM_LIBUNWIND=
WITH_LIBCPLUSPLUS=
WITHOUT_LLD_BOOTSTRAP=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_LLVM_TARGET_ALL=
amd64 head -r351153 self-built but via devel/llvm90: 'objcopy: elf_update() failed: Layout constraint violation' for gptboot.bin
I upgraded to head -r351153 and then attempted a buildworld buildkernel via devel/llvm90 (rc2 via ports head -r509054), but that (from scratch) build attempt got: --- gptboot.bin --- objcopy: elf_update() failed: Layout constraint violation *** [gptboot.bin] Error code 1 make[5]: *** gptboot.bin removed make[5]: stopped in /usr/src/stand/i386/gptboot .ERROR_TARGET='gptboot.bin' .ERROR_META_FILE='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/gptboot/gptboot.bin.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='objcopy -S -O binary gptboot.out gptboot.bin;' .CURDIR='/usr/src/stand/i386/gptboot' .MAKE='make' .OBJDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/gptboot' .TARGETS='all' DESTDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.amd64-xtoolchain-llvm.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/stand/i386/gptboot/Makefile /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/stand/i386/gptboot/../Makefile.inc /usr/src/share/mk/bsd.linker.mk /usr/src/stand/i386/gptboot/../../Makefile.inc /usr/src/stand/i386/gptboot/../../defs.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.nl s.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/i386/gptboot /usr/src/stand/i386/boot2 /usr/src/stand/i386/common /usr/src/stand/libsa' 1 error === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r351153 amd64 upgrade installworld failure: realinstall_subdir_stand got: 'sh: cc: not found' (a race?)
The below installworld material was after an apparently successful buildworld buildkernel then installkernel . Wrong stage for a cc producing loader_lua.sym ? (This was a normal, system-clang based build context, attempting an upgrade from head -r351102 .) --- realinstall_subdir_stand --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/stand/i386/btx/lib -nostdinc -I/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa32 -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT -I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -m32 -ffreestanding -mno-mmx -mno-sse -mno-avx -mno-avx2 -msoft-float -march=i386 -I. -I/usr/src/stand/common -I/usr/src/contrib/lua/src -I/usr/src/stand/common -I/usr/src/stand/liblua -DLUA_FLOAT_TYPE=LUA_FLOAT_INT64 -DLOADER_CD9660_SUPPORT -DLOADER_EXT2FS_SUPPORT -DLOADER_MSDOS_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_BZIP2_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -DLOADER_ZFS_SUPPORT -I/usr/src/stand/libsa/zfs -I/usr/src/sys/cddl /boot/zfs -Wall -I/usr/src--- realinstall_subdir_usr.sbin --- . . . --- realinstall_subdir_stand --- /stand/i386 -DLOADER_PREFER_AMD64 -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -nostdlib -static -Ttext 0x0 -Wl,--no-threads -Wl,--no-rosegment -o loader_lua.sym /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/lib/crt0.o main.o conf.o vers.o chain.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o load_elf32.o load_elf32_obj.o reloc_elf32.o load_elf64.o load_elf64_obj.o reloc_elf64.o disk.o part.o vdisk.o dev_net.o bcache.o isapnp.o pnp.o interp_lua.o zfs_cmd.o /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/ liblua32/liblua.a /usr/ob--- realinstall_subdir_share --- . . . --- realinstall_subdir_stand --- j/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/libi386/libi386.a /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa32/libsa32.a --- realinstall_subdir_tests --- . . . --- realinstall_subdir_stand --- sh: cc: not found Repeating buildworld buildkernel and then trying installworld (without the -j28 I had used originally) completed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
My 1st head -r351102 amd64->powerpc64 cross-build via devel/llvm90 failed, but it may be just operator error
My first attempt to cross buildworld buildkernel amd64->powerpc64
via devel/llvm90 without involving devel/powerpc64-binutils (or
other such) failed with:
--- gnu/lib/libssp/libssp_nonshared__PL ---
/usr/local/llvm90/bin/llvm-ranlib: error: Exactly one archive should be
specified.
OVERVIEW: LLVM Ranlib (llvm-ranlib)
This program generates an index to speed access to archives
USAGE: llvm-ranlib
OPTIONS:
-help - Display available options
-version - Display the version of this program
*** [libssp_nonshared.a] Error code 1
make[4]: *** libssp_nonshared.a removed
make[4]: stopped in /usr/src/gnu/lib/libssp/libssp_nonshared
.ERROR_TARGET='libssp_nonshared.a'
.ERROR_META_FILE='/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libssp/libssp_nonshared/libssp_nonshared.a.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='@echo building static ssp_nonshared library; @rm -f
libssp_nonshared.a; /usr/local/llvm90/bin/llvm-ar -crD libssp_nonshared.a
`NM='/usr/local/llvm90/bin/llvm-nm' NMFLAGS='' lorder ssp-local.o | tsort -q`
; /usr/local/llvm90/bin/llvm-ranlib -D libssp_nonshared.a;'
.CURDIR='/usr/src/gnu/lib/libssp/libssp_nonshared'
.MAKE='make'
.OBJDIR='/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libssp/libssp_nonshared'
.TARGETS='all'
DESTDIR='/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp'
LD_LIBRARY_PATH=''
MACHINE='powerpc'
MACHINE_ARCH='powerpc64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20181221'
PATH='/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk
/usr/src/share/mk/src.sys.env.mk
/root/src.configs/src.conf.powerpc64-xtoolchain-llvm.amd64-host
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk
/root/src.configs/make.conf /usr/src/share/mk/local.sys.mk
/usr/src/share/mk/src.sys.mk /dev/null
/usr/src/gnu/lib/libssp/libssp_nonshared/Makefile /usr/src/share/mk/bsd.lib.mk
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk
/usr/src/share/mk/src.init.mk /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk
/usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.libnames.mk
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bs
d.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/gnu/lib/libssp/libssp_nonshared
/usr/src/contrib/gcclibs/libssp /usr/src/contrib/gcclibs/libssp/ssp'
1 error
This was based on head -r351102 trying to cross-build itself and
on using:
# more ~/src.configs/src.conf.powerpc64-xtoolchain-llvm.amd64-host
TO_TYPE=powerpc64
LLVM_VINTAGE=llvm90
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
WITHOUT_SYSTEM_LINKER=
#
WITH_LLVM_LIBUNWIND=
WITH_LIBCPLUSPLUS=
WITHOUT_LLD_BOOTSTRAP=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_LLVM_TARGET_ALL=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITHOUT_BINUTILS=
WITHOUT_PORT_BASE_BINUTILS=
WITH_LLDB=
#
WITH_BOOT=
WITH_LIB32=
#
LOADER_DEFAULT_INTERP=4th
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
# Avoid build aborting for the likes of, for example,
# sign mismatch errors for integer types. Avoids:
# [-Werror,-Wpointer-sign]
#
WERROR=
MALLOC_PRODUCTION=
#
# Avoid stripping but do not control host -g status as well:
DEBUG_FLAGS+=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
#
CROSS_TOOLCHAIN=${LLVM_VINTAGE}
#X_COMPILER_TYPE=clang
CROSS_BINUTILS_PREFIX=/usr/local/${LLVM_V
head -r351102 amd64 rebuilding itself but via devel/xtoolchain-llvm90 ( rc2: ports head -r509054 ) fails for boot2.out: ld.lld: error: undefined symbol: __ashldi3
My attempt to have -r351102 rebuild itself via devel/llvm90 (rc2) got: --- all_subdir_stand --- --- boot2.out --- ld.lld: error: undefined symbol: __ashldi3 >>> referenced by ufsread.c:234 (/usr/src/stand/libsa/ufsread.c:234) >>> boot2.o:(fsread) >>> referenced by ufsread.c:270 (/usr/src/stand/libsa/ufsread.c:270) >>> boot2.o:(fsread) >>> referenced by ufsread.c:295 (/usr/src/stand/libsa/ufsread.c:295) >>> boot2.o:(fsread) >>> referenced by ufsread.c:297 (/usr/src/stand/libsa/ufsread.c:297) >>> boot2.o:(fsread) *** [boot2.out] Error code 1 make[5]: stopped in /usr/src/stand/i386/boot2 .ERROR_TARGET='boot2.out' .ERROR_META_FILE='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/boot2/boot2.out.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='/usr/local/llvm90/bin/ld.lld -m elf_i386_fbsd -static -N --gc-sections -Ttext 0x2000 -o boot2.out /usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/lib/crt0.o boot2.o sio.o;' .CURDIR='/usr/src/stand/i386/boot2' .MAKE='make' .OBJDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/stand/i386/boot2' .TARGETS='all' DESTDIR='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20181221' PATH='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.amd64-xtoolchain-llvm.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/stand/i386/boot2/Makefile /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/stand/i386/boot2/../Makefile.inc /usr/src/share/mk/bsd.linker.mk /usr/src/stand/i386/boot2/../../Makefile.inc /usr/src/stand/i386/boot2/../../defs.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.nls.mk /us r/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/i386/boot2' 1 error FYI: # uname -apKU FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT #29 r351102M: Thu Aug 15 14:22:00 PDT 2019 markmi@FBSDFHUGE:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1300039 1300039 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
[I found that the vintage of cmake matters: 3.12 and
earlier work differently. Details later.]
On 2019-Aug-7, at 14:37, Mark Millard wrote:
> On 2019-Aug-7, at 13:58, Brooks Davis wrote:
>
>> On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote:
>>>
>>>
>>> On 2019-Aug-7, at 12:56, Brooks Davis wrote:
>>>
On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
>
>> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
>>> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
[I found something known to be missing in the
in at least some versions of
llvm/cmake/modules/CrossCompile.cmake that messes
up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
On 2019-Aug-6, at 20:23, Mark Millard wrote:
> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
>
>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
>>>
>>>
>>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
>>>
I'd prefer to disable this dependency. There's a knob that worked
in
the 8.0 timeframe, but the lit build now autodetects z3 when it is
present and I've failed to find a knob to disable it. For now,
the easy
workaround is probably to disable options LIT. We could make that
the
default on non-LLVM platforms is that makes sense.
-- Brooks
>>>
>>> Okay.
>>>
>>> poudriere-devel automatically built math/z3 because
>>> I'd indicated to build devel/llvm90 . math/z3 was not
>>> previously built: I've never had other use of it. So
>>> my context was not one of an implicit autodetect.
>>
>> The dependency is there because if z3 is installed then the package
>> that is built depends on z3. Thus I had not choice but to add a z3
>> dependency until I find a way to turn it off. You can either help
>> find
>> a way to disable z3 detection in the cmake infrastructure or turn off
>> LIT. I don't have any use for reports on the effects of commenting
>> out
>> the DEPENDS line. I know what that does.
>
>
> I hope this helps. (I'm not a cmake expert.)
>
> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
>
> #if LLVM_WITH_Z3
>
> #include
>
> namespace {
> . . .
> } // end anonymous namespace
>
> #endif
>
> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> #if LLVM_WITH_Z3
> return llvm::make_unique();
> #else
> llvm::report_fatal_error("LLVM was not compiled with Z3 support,
> rebuild "
>"with -DLLVM_ENABLE_Z3_SOLVER=ON",
>false);
> return nullptr;
> #endif
> }
>
> (There are other places LLVM_WITH_Z3 is used but the
> above is suggestive.)
>
> Working backwards finds that:
>
> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
>
> shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
>
> set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> solver.")
>
> find_package(Z3 4.7.1)
>
> if (LLVM_Z3_INSTALL_DIR)
> if (NOT Z3_FOUND)
> message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> endif()
> endif()
>
> set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
>
> option(LLVM_ENABLE_Z3_SOLVER
> "Enable Support for the Z3 constraint solver in LLVM."
> ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> )
>
> if (LLVM_ENABLE_Z3_SOLVER)
> if (NOT Z3_FOUND)
> message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3
> is not available.")
> endif()
>
> set(LLVM_WITH_Z3 1)
> endif()
>
> if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> endif()
>
>
> If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> appears to override the default (that tracks if z3 was found).
I saw a reference to:
diff --git a/llvm/cmake/modules/CrossCompile.cmake
b/llvm/cmake/modules/CrossCompile.cmake
index bc3b210f018..0c30b88f80f 100644
--- a/llvm/cmake/modules/CrossCompile.cmake
+++ b/llvm/cmake/modules/CrossCompile.cmake
>>>
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On 2019-Aug-7, at 13:58, Brooks Davis wrote:
> On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote:
>>
>>
>> On 2019-Aug-7, at 12:56, Brooks Davis wrote:
>>
>>> On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
On 2019-Aug-7, at 11:02, Brooks Davis wrote:
> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
>> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
>>> [I found something known to be missing in the
>>> in at least some versions of
>>> llvm/cmake/modules/CrossCompile.cmake that messes
>>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
>>>
>>> On 2019-Aug-6, at 20:23, Mark Millard wrote:
>>>
>>>
>>>
On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
>>
>>
>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
>>
>>> I'd prefer to disable this dependency. There's a knob that worked
>>> in
>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
>>> present and I've failed to find a knob to disable it. For now, the
>>> easy
>>> workaround is probably to disable options LIT. We could make that
>>> the
>>> default on non-LLVM platforms is that makes sense.
>>>
>>> -- Brooks
>>
>> Okay.
>>
>> poudriere-devel automatically built math/z3 because
>> I'd indicated to build devel/llvm90 . math/z3 was not
>> previously built: I've never had other use of it. So
>> my context was not one of an implicit autodetect.
>
> The dependency is there because if z3 is installed then the package
> that is built depends on z3. Thus I had not choice but to add a z3
> dependency until I find a way to turn it off. You can either help
> find
> a way to disable z3 detection in the cmake infrastructure or turn off
> LIT. I don't have any use for reports on the effects of commenting
> out
> the DEPENDS line. I know what that does.
I hope this helps. (I'm not a cmake expert.)
llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
#if LLVM_WITH_Z3
#include
namespace {
. . .
} // end anonymous namespace
#endif
llvm::SMTSolverRef llvm::CreateZ3Solver() {
#if LLVM_WITH_Z3
return llvm::make_unique();
#else
llvm::report_fatal_error("LLVM was not compiled with Z3 support,
rebuild "
"with -DLLVM_ENABLE_Z3_SOLVER=ON",
false);
return nullptr;
#endif
}
(There are other places LLVM_WITH_Z3 is used but the
above is suggestive.)
Working backwards finds that:
/wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
solver.")
find_package(Z3 4.7.1)
if (LLVM_Z3_INSTALL_DIR)
if (NOT Z3_FOUND)
message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
endif()
endif()
set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
option(LLVM_ENABLE_Z3_SOLVER
"Enable Support for the Z3 constraint solver in LLVM."
${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
)
if (LLVM_ENABLE_Z3_SOLVER)
if (NOT Z3_FOUND)
message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3
is not available.")
endif()
set(LLVM_WITH_Z3 1)
endif()
if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
endif()
If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
appears to override the default (that tracks if z3 was found).
>>>
>>> I saw a reference to:
>>>
>>> diff --git a/llvm/cmake/modules/CrossCompile.cmake
>>> b/llvm/cmake/modules/CrossCompile.cmake
>>> index bc3b210f018..0c30b88f80f 100644
>>> --- a/llvm/cmake/modules/CrossCompile.cmake
>>> +++ b/llvm/cmake/modules/CrossCompile.cmake
>>> @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal
>>> target_name toolchain buildtype)
>>> -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
>>> -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
>>>
>>> -DLLVM_TEMPORARILY_ALLOW_OLD_T
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On 2019-Aug-7, at 12:56, Brooks Davis wrote:
> On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
>>
>>
>> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
>>
>>> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> [I found something known to be missing in the
> in at least some versions of
> llvm/cmake/modules/CrossCompile.cmake that messes
> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
>
> On 2019-Aug-6, at 20:23, Mark Millard wrote:
>
>
>
>> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
>>
>>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> I'd prefer to disable this dependency. There's a knob that worked in
> the 8.0 timeframe, but the lit build now autodetects z3 when it is
> present and I've failed to find a knob to disable it. For now, the
> easy
> workaround is probably to disable options LIT. We could make that the
> default on non-LLVM platforms is that makes sense.
>
> -- Brooks
Okay.
poudriere-devel automatically built math/z3 because
I'd indicated to build devel/llvm90 . math/z3 was not
previously built: I've never had other use of it. So
my context was not one of an implicit autodetect.
>>>
>>> The dependency is there because if z3 is installed then the package
>>> that is built depends on z3. Thus I had not choice but to add a z3
>>> dependency until I find a way to turn it off. You can either help find
>>> a way to disable z3 detection in the cmake infrastructure or turn off
>>> LIT. I don't have any use for reports on the effects of commenting out
>>> the DEPENDS line. I know what that does.
>>
>>
>> I hope this helps. (I'm not a cmake expert.)
>>
>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
>>
>> #if LLVM_WITH_Z3
>>
>> #include
>>
>> namespace {
>> . . .
>> } // end anonymous namespace
>>
>> #endif
>>
>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
>> #if LLVM_WITH_Z3
>> return llvm::make_unique();
>> #else
>> llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
>> "
>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
>> false);
>> return nullptr;
>> #endif
>> }
>>
>> (There are other places LLVM_WITH_Z3 is used but the
>> above is suggestive.)
>>
>> Working backwards finds that:
>>
>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
>>
>> shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
>>
>> set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
>> solver.")
>>
>> find_package(Z3 4.7.1)
>>
>> if (LLVM_Z3_INSTALL_DIR)
>> if (NOT Z3_FOUND)
>> message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
>> LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
>> endif()
>> endif()
>>
>> set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
>>
>> option(LLVM_ENABLE_Z3_SOLVER
>> "Enable Support for the Z3 constraint solver in LLVM."
>> ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
>> )
>>
>> if (LLVM_ENABLE_Z3_SOLVER)
>> if (NOT Z3_FOUND)
>> message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is
>> not available.")
>> endif()
>>
>> set(LLVM_WITH_Z3 1)
>> endif()
>>
>> if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
>> set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
>> endif()
>>
>>
>> If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
>> appears to override the default (that tracks if z3 was found).
>
> I saw a reference to:
>
> diff --git a/llvm/cmake/modules/CrossCompile.cmake
> b/llvm/cmake/modules/CrossCompile.cmake
> index bc3b210f018..0c30b88f80f 100644
> --- a/llvm/cmake/modules/CrossCompile.cmake
> +++ b/llvm/cmake/modules/CrossCompile.cmake
> @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name
> toolchain buildtype)
>-DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
>-DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
>
> -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
> +-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
>${build_type_flags} ${linker_flag} ${external_clang_dir}
>WORKING_DIRECTORY ${LLVM_${target_name}_BUILD}
>DEPENDS CREATE_LLVM_${target_name}
>
> in https://reviews.llvm.org/D54978 on Feb 12 2019, 5:41 PM
> and it had the comment:
>
> QUOTE
> Independent of
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On 2019-Aug-7, at 11:02, Brooks Davis wrote:
> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
>> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
>>> [I found something known to be missing in the
>>> in at least some versions of
>>> llvm/cmake/modules/CrossCompile.cmake that messes
>>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
>>>
>>> On 2019-Aug-6, at 20:23, Mark Millard wrote:
>>>
>>>
>>>
On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
>>
>>
>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
>>
>>> I'd prefer to disable this dependency. There's a knob that worked in
>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
>>> present and I've failed to find a knob to disable it. For now, the easy
>>> workaround is probably to disable options LIT. We could make that the
>>> default on non-LLVM platforms is that makes sense.
>>>
>>> -- Brooks
>>
>> Okay.
>>
>> poudriere-devel automatically built math/z3 because
>> I'd indicated to build devel/llvm90 . math/z3 was not
>> previously built: I've never had other use of it. So
>> my context was not one of an implicit autodetect.
>
> The dependency is there because if z3 is installed then the package
> that is built depends on z3. Thus I had not choice but to add a z3
> dependency until I find a way to turn it off. You can either help find
> a way to disable z3 detection in the cmake infrastructure or turn off
> LIT. I don't have any use for reports on the effects of commenting out
> the DEPENDS line. I know what that does.
I hope this helps. (I'm not a cmake expert.)
llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
#if LLVM_WITH_Z3
#include
namespace {
. . .
} // end anonymous namespace
#endif
llvm::SMTSolverRef llvm::CreateZ3Solver() {
#if LLVM_WITH_Z3
return llvm::make_unique();
#else
llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild "
"with -DLLVM_ENABLE_Z3_SOLVER=ON",
false);
return nullptr;
#endif
}
(There are other places LLVM_WITH_Z3 is used but the
above is suggestive.)
Working backwards finds that:
/wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
solver.")
find_package(Z3 4.7.1)
if (LLVM_Z3_INSTALL_DIR)
if (NOT Z3_FOUND)
message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
endif()
endif()
set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
option(LLVM_ENABLE_Z3_SOLVER
"Enable Support for the Z3 constraint solver in LLVM."
${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
)
if (LLVM_ENABLE_Z3_SOLVER)
if (NOT Z3_FOUND)
message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is
not available.")
endif()
set(LLVM_WITH_Z3 1)
endif()
if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
endif()
If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
appears to override the default (that tracks if z3 was found).
>>>
>>> I saw a reference to:
>>>
>>> diff --git a/llvm/cmake/modules/CrossCompile.cmake
>>> b/llvm/cmake/modules/CrossCompile.cmake
>>> index bc3b210f018..0c30b88f80f 100644
>>> --- a/llvm/cmake/modules/CrossCompile.cmake
>>> +++ b/llvm/cmake/modules/CrossCompile.cmake
>>> @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name
>>> toolchain buildtype)
>>> -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
>>> -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
>>>
>>> -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
>>> +-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
>>> ${build_type_flags} ${linker_flag} ${external_clang_dir}
>>> WORKING_DIRECTORY ${LLVM_${target_name}_BUILD}
>>> DEPENDS CREATE_LLVM_${target_name}
>>>
>>> in https://reviews.llvm.org/D54978 on Feb 12 2019, 5:41 PM
>>> and it had the comment:
>>>
>>> QUOTE
>>> Independent of the rest of the discussion, this patch should be part of the
>>> reland, to make sure that explicitly turning off Z3 works reliably. Thanks
>>> for coming up with that, and thanks everyone for the good discussion here :)
>>> END QUOTE
>>>
>>> This apparently fixes a sub-cmake not respecting the
>>> LLVM_ENABLE_Z3_SOLVER setting in the parent cmake.
>>> (The overall review earlier describes the s
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
[I found something known to be missing in the
in at least some versions of
llvm/cmake/modules/CrossCompile.cmake that messes
up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
On 2019-Aug-6, at 20:23, Mark Millard wrote:
> On 2019-Aug-6, at 19:08, Brooks Davis wrote:
>
>> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
>>>
>>>
>>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
>>>
I'd prefer to disable this dependency. There's a knob that worked in
the 8.0 timeframe, but the lit build now autodetects z3 when it is
present and I've failed to find a knob to disable it. For now, the easy
workaround is probably to disable options LIT. We could make that the
default on non-LLVM platforms is that makes sense.
-- Brooks
>>>
>>> Okay.
>>>
>>> poudriere-devel automatically built math/z3 because
>>> I'd indicated to build devel/llvm90 . math/z3 was not
>>> previously built: I've never had other use of it. So
>>> my context was not one of an implicit autodetect.
>>
>> The dependency is there because if z3 is installed then the package
>> that is built depends on z3. Thus I had not choice but to add a z3
>> dependency until I find a way to turn it off. You can either help find
>> a way to disable z3 detection in the cmake infrastructure or turn off
>> LIT. I don't have any use for reports on the effects of commenting out
>> the DEPENDS line. I know what that does.
>
>
> I hope this helps. (I'm not a cmake expert.)
>
> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
>
> #if LLVM_WITH_Z3
>
> #include
>
> namespace {
> . . .
> } // end anonymous namespace
>
> #endif
>
> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> #if LLVM_WITH_Z3
> return llvm::make_unique();
> #else
> llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild "
> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> false);
> return nullptr;
> #endif
> }
>
> (There are other places LLVM_WITH_Z3 is used but the
> above is suggestive.)
>
> Working backwards finds that:
>
> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
>
> shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
>
> set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3 solver.")
>
> find_package(Z3 4.7.1)
>
> if (LLVM_Z3_INSTALL_DIR)
> if (NOT Z3_FOUND)
>message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> endif()
> endif()
>
> set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
>
> option(LLVM_ENABLE_Z3_SOLVER
> "Enable Support for the Z3 constraint solver in LLVM."
> ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> )
>
> if (LLVM_ENABLE_Z3_SOLVER)
> if (NOT Z3_FOUND)
>message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is
> not available.")
> endif()
>
> set(LLVM_WITH_Z3 1)
> endif()
>
> if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> endif()
>
>
> If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> appears to override the default (that tracks if z3 was found).
I saw a reference to:
diff --git a/llvm/cmake/modules/CrossCompile.cmake
b/llvm/cmake/modules/CrossCompile.cmake
index bc3b210f018..0c30b88f80f 100644
--- a/llvm/cmake/modules/CrossCompile.cmake
+++ b/llvm/cmake/modules/CrossCompile.cmake
@@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name
toolchain buildtype)
-DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
-DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
+-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
${build_type_flags} ${linker_flag} ${external_clang_dir}
WORKING_DIRECTORY ${LLVM_${target_name}_BUILD}
DEPENDS CREATE_LLVM_${target_name}
in https://reviews.llvm.org/D54978 on Feb 12 2019, 5:41 PM
and it had the comment:
QUOTE
Independent of the rest of the discussion, this patch should be part of the
reland, to make sure that explicitly turning off Z3 works reliably. Thanks for
coming up with that, and thanks everyone for the good discussion here :)
END QUOTE
This apparently fixes a sub-cmake not respecting the
LLVM_ENABLE_Z3_SOLVER setting in the parent cmake.
(The overall review earlier describes the sub-cmake
not doing the right thing.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
>>
>>
>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
>>
>>> I'd prefer to disable this dependency. There's a knob that worked in
>>> the 8.0 timeframe, but the lit build now autodetects z3 when it is
>>> present and I've failed to find a knob to disable it. For now, the easy
>>> workaround is probably to disable options LIT. We could make that the
>>> default on non-LLVM platforms is that makes sense.
>>>
>>> -- Brooks
>>
>> Okay.
>>
>> poudriere-devel automatically built math/z3 because
>> I'd indicated to build devel/llvm90 . math/z3 was not
>> previously built: I've never had other use of it. So
>> my context was not one of an implicit autodetect.
>
> The dependency is there because if z3 is installed then the package
> that is built depends on z3. Thus I had not choice but to add a z3
> dependency until I find a way to turn it off. You can either help find
> a way to disable z3 detection in the cmake infrastructure or turn off
> LIT. I don't have any use for reports on the effects of commenting out
> the DEPENDS line. I know what that does.
I hope this helps. (I'm not a cmake expert.)
llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
#if LLVM_WITH_Z3
#include
namespace {
. . .
} // end anonymous namespace
#endif
llvm::SMTSolverRef llvm::CreateZ3Solver() {
#if LLVM_WITH_Z3
return llvm::make_unique();
#else
llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild "
"with -DLLVM_ENABLE_Z3_SOLVER=ON",
false);
return nullptr;
#endif
}
(There are other places LLVM_WITH_Z3 is used but the
above is suggestive.)
Working backwards finds that:
/wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3 solver.")
find_package(Z3 4.7.1)
if (LLVM_Z3_INSTALL_DIR)
if (NOT Z3_FOUND)
message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in LLVM_Z3_INSTALL_DIR:
${LLVM_Z3_INSTALL_DIR}.")
endif()
endif()
set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
option(LLVM_ENABLE_Z3_SOLVER
"Enable Support for the Z3 constraint solver in LLVM."
${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
)
if (LLVM_ENABLE_Z3_SOLVER)
if (NOT Z3_FOUND)
message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is not
available.")
endif()
set(LLVM_WITH_Z3 1)
endif()
if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
endif()
If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
appears to override the default (that tracks if z3 was found).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
[This note is not for Brooks and I'm not sending directly to him.
It is for others that may be exploring before his "either/or" is
figured out for general builds.]
On 2019-Aug-6, at 19:04, Mark Millard wrote:
> On 2019-Aug-6, at 17:59, Mark Millard wrote:
>
>
>
>>> . . .
>>
>> poudriere-devel automatically built math/z3 because
>> I'd indicated to build devel/llvm90 . math/z3 was not
>> previously built: I've never had other use of it. So
>> my context was not one of an implicit autodetect.
>>
>> It looks like that happened because of
>> devel/llvm90/Makefile having:
>>
>> LIT_DESC= Install lit and FileCheck test tools
>> LIT_LIB_DEPENDS=libz3.so:math/z3
>> LIT_VARS= _USES_PYTHON=python:3.6+
>
> I tried deleting the package for math/z3 from
> poudriere and using:
>
> FBSDFHUGE# svnlite diff /usr/ports/devel/llvm90
> Index: /usr/ports/devel/llvm90/Makefile
> ===
> --- /usr/ports/devel/llvm90/Makefile (revision 508197)
> +++ /usr/ports/devel/llvm90/Makefile (working copy)
> @@ -110,7 +110,7 @@
> GOLD_CMAKE_ON=-DLLVM_BINUTILS_INCDIR=${LOCALBASE}/include
> GOLD_BUILD_DEPENDS= ${LOCALBASE}/bin/ld.gold:devel/binutils
> LIT_DESC= Install lit and FileCheck test tools
> -LIT_LIB_DEPENDS= libz3.so:math/z3
> +#LIT_LIB_DEPENDS=libz3.so:math/z3
> LIT_VARS= _USES_PYTHON=python:3.6+
> LLD_DESC= Install lld, the LLVM linker
> LLD_DISTFILES=lld-${DISTVERSION}.src${EXTRACT_SUFX}
>
> devel/llvm90 is building via poudriere-devel without
> first building math/z3 . We will see if it completes
> okay.
>
> If it does I'll try a pkg delete of math/z3 and
> an install of the devel/llvm90 .
>
> . . .
The above makes poudriere builds of devel/llvm90 not depend
on libz3.so and does not try to build math/z3 or to put it
in place during the llvm90 build. But it would apparently
not help portmaster or the like avoid creating the dependency
if libz3.so was in place.
So poudriere users appear to have a way around the math/z3
consequences for now.
One of the consequences was the messages about:
OMP: Info #270: omp_set_nested routine deprecated, please use
omp_set_max_active_levels instead.
Those are also gone by building and installing via
poudriere with such a devel/llvm90/Makefile .
It looks like portmaster or such needs to be used to see if
one has successfully disabled automatic libz3.so detection
in llvm90's cmake infrastructure. (I normally build via
poudriere-devel .)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80078c000) > libc.so.7 => /lib/libc.so.7 (0x800242000) > > This makes clear that mixing in libstdc+++ or the > like would likely not be appropriate unless llvm90 > was also using such. So a default gcc based build > of libz3.so likely would not be appropriate if > llvm90 is to also be built such that it can bind > to libz3.so if found. > >> On Mon, Aug 05, 2019 at 08:45:31PM -0700, Mark Millard via freebsd-toolchain >> wrote: >>> Building math/z3 involves: >>> >>> # grep compiler /usr/ports/math/z3/Makefile >>> USES= compiler:c++11-lang python:2.7,build >>> >>> But devel/llvm90 requires math/z3 to have been built before >>> devel/llvm90 is built: >>> >>> # pkg info -d llvm90 >>> llvm90-9.0.0.r1: >>> libxml2-2.9.9 >>> z3-4.8.5_1 >>> python36-3.6.9 >>> perl5-5.28.2 >>> libedit-3.1.20190324,1 >>> # pkg info -B llvm90 >>> llvm90-9.0.0.r1: >>> libpython3.6m.so.1.0 >>> libedit.so.0 >>> libz3.so.0 >>> libxml2.so.2 >>> >>> >>> Hopefully this cycle can be avoided for system >>> clang to eventually have progressed to clang 9. >>> (I do not know the details.) >>> >>> For architectures still at gcc/g++ 4.2.1, some >>> alternate c++ tool chain needs to be used to >>> build libz3.so but the result needs to be >>> compatible with llvm90 later using the libz3.so's >>> content. (I do not know the details.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
On 2019-Aug-6, at 09:55, Brooks Davis wrote: > I'd prefer to disable this dependency. There's a knob that worked in > the 8.0 timeframe, but the lit build now autodetects z3 when it is > present and I've failed to find a knob to disable it. For now, the easy > workaround is probably to disable options LIT. We could make that the > default on non-LLVM platforms is that makes sense. > > -- Brooks Okay. poudriere-devel automatically built math/z3 because I'd indicated to build devel/llvm90 . math/z3 was not previously built: I've never had other use of it. So my context was not one of an implicit autodetect. It looks like that happened because of devel/llvm90/Makefile having: LIT_DESC= Install lit and FileCheck test tools LIT_LIB_DEPENDS=libz3.so:math/z3 LIT_VARS= _USES_PYTHON=python:3.6+ Of course someone that has math/z3 for other reasons would not necessarily want it used by llvm90 materials, so merely not listing it in LIT_LIB_DEPENDS might not be enough to cover all contexts. [Stop reading here if you do not care about what from llvm90 uses z3 and some of the consequences.] It turns out that the direct dependency is (via reviewing ldd -a output): /usr/local/llvm90/lib/../lib/libLLVM-9.so: libz3.so.0 => /usr/local/lib/libz3.so.0 The indirect reference via libLLVM-9.so use leads to most of llvm90 materials binding to libz3.so : # ldd /usr/local/llvm90/lib/*.so | egrep '(^/|z3)' /usr/local/llvm90/lib/CheckerDependencyHandlingAnalyzerPlugin.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x807a0) /usr/local/llvm90/lib/CheckerOptionHandlingAnalyzerPlugin.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x807a0) /usr/local/llvm90/lib/LLVMgold.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80540) /usr/local/llvm90/lib/SampleAnalyzerPlugin.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x807a0) /usr/local/llvm90/lib/libLLVM-9.0.0.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80520) /usr/local/llvm90/lib/libLLVM-9.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80520) /usr/local/llvm90/lib/libLLVM.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80520) /usr/local/llvm90/lib/libLTO.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80540) /usr/local/llvm90/lib/libRemarks.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80540) /usr/local/llvm90/lib/libclang-cpp.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x807a0) /usr/local/llvm90/lib/libclang.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x80720) /usr/local/llvm90/lib/libgomp.so: /usr/local/llvm90/lib/libiomp5.so: /usr/local/llvm90/lib/liblldb.so: libz3.so.0 => /usr/local/lib/libz3.so.0 (0x807e0) /usr/local/llvm90/lib/libomp.so: /usr/local/llvm90/lib/libomptarget.so: (I'll not list the /usr/local/llvm90/bin/ programs that in turn bind to these libraries, but most end up bound to libz3.so .) ldd reports some of the details as far as what librraries the libz3.so depends on: # ldd /usr/local/lib/*z3.so /usr/local/lib/libz3.so: libthr.so.3 => /lib/libthr.so.3 (0x800662000) libomp.so => /usr/lib/libomp.so (0x80068f000) libc++.so.1 => /usr/lib/libc++.so.1 (0x8020e4000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800738000) libm.so.5 => /lib/libm.so.5 (0x80075a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80078c000) libc.so.7 => /lib/libc.so.7 (0x800242000) This makes clear that mixing in libstdc+++ or the like would likely not be appropriate unless llvm90 was also using such. So a default gcc based build of libz3.so likely would not be appropriate if llvm90 is to also be built such that it can bind to libz3.so if found. > On Mon, Aug 05, 2019 at 08:45:31PM -0700, Mark Millard via freebsd-toolchain > wrote: >> Building math/z3 involves: >> >> # grep compiler /usr/ports/math/z3/Makefile >> USES=compiler:c++11-lang python:2.7,build >> >> But devel/llvm90 requires math/z3 to have been built before >> devel/llvm90 is built: >> >> # pkg info -d llvm90 >> llvm90-9.0.0.r1: >> libxml2-2.9.9 >> z3-4.8.5_1 >> python36-3.6.9 >> perl5-5.28.2 >> libedit-3.1.20190324,1 >> # pkg info -B llvm90 >> llvm90-9.0.0.r1: >> libpython3.6m.so.1.0 >> libedit.so.0 >> libz3.so.0 >> libxml2.so.2 >> >> >> Hopefully this cycle can be avoided for system >> clang to eventually have progressed to clang 9. >> (I do not know the details.) >> >> For architectures still at gcc/g++ 4.2.1, some >> alternate c++ tool chain needs to be used to >> build libz3.so but the result needs to be >> com
devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
Building math/z3 involves: # grep compiler /usr/ports/math/z3/Makefile USES= compiler:c++11-lang python:2.7,build But devel/llvm90 requires math/z3 to have been built before devel/llvm90 is built: # pkg info -d llvm90 llvm90-9.0.0.r1: libxml2-2.9.9 z3-4.8.5_1 python36-3.6.9 perl5-5.28.2 libedit-3.1.20190324,1 # pkg info -B llvm90 llvm90-9.0.0.r1: libpython3.6m.so.1.0 libedit.so.0 libz3.so.0 libxml2.so.2 Hopefully this cycle can be avoided for system clang to eventually have progressed to clang 9. (I do not know the details.) For architectures still at gcc/g++ 4.2.1, some alternate c++ tool chain needs to be used to build libz3.so but the result needs to be compatible with llvm90 later using the libz3.so's content. (I do not know the details.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Attempted buildworlds via devel/llvm90 failed for: undefined symbol: bcmp / undefined reference to `bcmp'
amd64 (self hosted): --- all_subdir_libexec --- ld: error: undefined symbol: bcmp >>> referenced by strstr.c:121 (/usr/src/lib/libc/string/strstr.c:121) >>> strstr.nossppico:(strstr) in archive >>> /usr/obj/amd64_xtoolchain-llvm/amd64.amd64/usr/src/amd64.amd64/libexec/rtld-elf/rtld_libc.a clang-9: error: linker command failed with exit code 1 (use -v to see invocation) amd64->powerpc64 cross build: --- all_subdir_libexec --- /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: /usr/obj/powerpc64vtsc_xtoolchain-llvm/powerpc.powerpc64/usr/src/powerpc.powerpc64/libexec/rtld-elf/rtld_libc.a(strstr.nossppico): in function `twoway_strstr': /usr/src/lib/libc/string/strstr.c:121: undefined reference to `bcmp' === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
devel/llvm90 based buildworld: lots of notices of "OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead"
After building devel/llvm90 on amd64 I started a buildworld buildkernel based on it (amd64 self-hosted). It is producing thousands of notices: OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead. It is still building but at this point: # grep 'OMP: Info #' /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolchain-llvm-amd64-host-2019-08-05:18:34:34 | wc 26534 265334 2600253 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: amd64->armv7 cross build: devel/llvm90 build blocked by math/z3 build failure: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol: __stack_chk_guard in readonly segment
On 2019-Aug-5, at 14:48, Mark Millard wrote:
[Note: Targeting aarch64 instead did not have this problem.]
>
> [00:03:02] [02] [00:00:00] Building math/z3 | z3-4.8.5_1
> . . .
> [00:06:31] [02] [00:03:29] Saved math/z3 | z3-4.8.5_1 wrkdir to:
> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/z3-4.8.5_1.tar
> [00:06:31] [02] [00:03:29] Finished math/z3 | z3-4.8.5_1: Failed: build
> . . .
> [00:06:35] [02] [00:03:33] Skipping devel/llvm90 | llvm90-9.0.0.r1: Dependent
> port math/z3 | z3-4.8.5_1 failed
>
> The specific first errors for math/z3 were:
>
> ld: error: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol:
> __stack_chk_guard in readonly segment; recompile object files with -fPIC or
> pass '-Wl,-z,notext' to allow text relocations
> in the output
defined in /lib/libc.so.7
referenced by install_tactic.cpp:97 (../src/api/dll/install_tactic.cpp:97)
api/dll/install_tactic.o:(install_tactics(tactic_manager&))
>
> ld: error: can't create dynamic relocation R_ARM_MOVT_ABS against symbol:
> __stack_chk_guard in readonly segment; recompile object files with -fPIC or
> pass '-Wl,-z,notext' to allow text relocations in the output
defined in /lib/libc.so.7
referenced by install_tactic.cpp:97 (../src/api/dll/install_tactic.cpp:97)
api/dll/install_tactic.o:(install_tactics(tactic_manager&))
>
> ld: error: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol:
> .L.str in readonly segment; recompile object files with -fPIC or pass
> '-Wl,-z,notext' to allow text relocations in the output
defined in api/dll/install_tactic.o
referenced by install_tactic.cpp:98 (../src/api/dll/install_tactic.cpp:98)
api/dll/install_tactic.o:(install_tactics(tactic_manager&))
>
>
> Is the default:
>
> STATIC=on: Build static z3 library
>
> inappropriate for armv7?
>
Even with:
. . . -Wl,-znotext -Wl,-soname,libz3.so.0
via:
# svnlite diff /usr/ports/math/z3
Index: /usr/ports/math/z3/Makefile
===
--- /usr/ports/math/z3/Makefile (revision 508197)
+++ /usr/ports/math/z3/Makefile (working copy)
@@ -36,6 +36,7 @@
GMP_LIB_DEPENDS= libgmp.so:math/gmp
LDFLAGS_i386= -Wl,-znotext
+LDFLAGS_armv7= -Wl,-znotext
BUILD_WRKSRC= ${WRKSRC}/build
INSTALL_WRKSRC=${WRKSRC}/build
I get some of the errors:
ld: error: relocation R_ARM_MOVW_ABS_NC cannot be used against symbol
__stack_chk_guard; recompile with -fPIC
>>> defined in /lib/libc.so.7
>>> referenced by install_tactic.cpp:97 (../src/api/dll/install_tactic.cpp:97)
>>> api/dll/install_tactic.o:(install_tactics(tactic_manager&))
. . .
ld: error: relocation R_ARM_MOVT_ABS cannot be used against symbol
__stack_chk_guard; recompile with -fPIC
>>> defined in /lib/libc.so.7
>>> referenced by gparams_register_modules.cpp:93
>>> (../src/api/dll/gparams_register_modules.cpp:93)
>>>
>>> api/dll/gparams_register_modules.o:(gparams_register_modules())
ld: error: relocation R_ARM_MOVW_ABS_NC cannot be used against symbol
g_z3_log_enabled; recompile with -fPIC
>>> defined in api/api_log.o
>>> referenced by api_log_macros.h:11 (../src/api/api_log_macros.h:11)
>>> api/api_algebraic.o:(Z3_algebraic_is_value)
. . .
Currently building llvm90 on/for armv7 is blocked by needing
to build math/z3 first.
(For FreeBSD to switch from clang 8 to clang 9 as the system
compiler might require adding z3 to FreeBSD?)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
amd64->armv7 cross build: devel/llvm90 build blocked by math/z3 build failure: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol: __stack_chk_guard in readonly segment
[Note: Targeting aarch64 instead did not have this problem.] [00:03:02] [02] [00:00:00] Building math/z3 | z3-4.8.5_1 . . . [00:06:31] [02] [00:03:29] Saved math/z3 | z3-4.8.5_1 wrkdir to: /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/z3-4.8.5_1.tar [00:06:31] [02] [00:03:29] Finished math/z3 | z3-4.8.5_1: Failed: build . . . [00:06:35] [02] [00:03:33] Skipping devel/llvm90 | llvm90-9.0.0.r1: Dependent port math/z3 | z3-4.8.5_1 failed The specific first errors for math/z3 were: ld: error: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol: __stack_chk_guard in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /lib/libc.so.7 >>> referenced by install_tactic.cpp:97 (../src/api/dll/install_tactic.cpp:97) >>> api/dll/install_tactic.o:(install_tactics(tactic_manager&)) ld: error: can't create dynamic relocation R_ARM_MOVT_ABS against symbol: __stack_chk_guard in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /lib/libc.so.7 >>> referenced by install_tactic.cpp:97 (../src/api/dll/install_tactic.cpp:97) >>> api/dll/install_tactic.o:(install_tactics(tactic_manager&)) ld: error: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol: .L.str in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in api/dll/install_tactic.o >>> referenced by install_tactic.cpp:98 (../src/api/dll/install_tactic.cpp:98) >>> api/dll/install_tactic.o:(install_tactics(tactic_manager&)) Is the default: STATIC=on: Build static z3 library inappropriate for armv7? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
system-clang system-lld used to amd64->powerpc (32-bit) cross-build: lld with "-m" "elf32ppc_fbsd" is not enough to allow --secure-plt
Sometime at or before head -r349444 my historical src.conf variant that I use to attempt amd64->powerpc cross-build to using system-ld (lld) started reporting: --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 347: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 352: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. . . . --- libc.so.7.full --- ld: error: unknown argument: --secure-plt cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libc.so.7.full] Error code 1 The libc.so.7.full.meta file reports the CMD as (ignoring the part for the huge *.pico file list): cc -target powerpc-unknown-freebsd13.0 --sysroot=/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/bin -Wl,--secure-plt -nodefaultlibs -Wl,--version-script=Version.map -Wl,--no-threads -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 Adding -### and executing that reports ( on -r349794 ): (lines split for readability) FreeBSD clang version 8.0.1 (branches/release_80 364487) (based on LLVM 8.0.1) Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/ld" \ "--sysroot=/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp" \ "--eh-frame-hdr" "-Bshareable" "--enable-new-dtags" \ "-m" "elf32ppc_fbsd" \ "-o" "libc.so.7.full" \ "/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crti.o" \ "/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o" \ "-L/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib" \ "--secure-plt" \ "--version-script=Version.map" "--no-threads" "-x" "--fatal-warnings" "--warn-shared-textrel" \ "-soname" "libc.so.7" \ "/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtendS.o" \ "/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtn.o" Executing the full reported "/usr/bin/ld" produces: ld: error: unknown argument: --secure-plt So "-m" "elf32ppc_fbsd" was insufficient to enable allowing --secure-plt (a powerpc 32-bit specific option). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
system-clang devel/powerpc64-binutils used to amd64->powerpc (32-bit) cross-build vs. the ld's secture-plt criteria: leads to build failure
Sometime at or before head -r349444 my historical src.conf variant
that i use to amd64->powerpc cross-build using devel/powerpc64-binutils
stopped working, getting:
--- libc.so.7.full ---
building shared library libc.so.7
/usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to
/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libc.so.7.full] Error code 1
(I had not updated the head revision for a long time before
jumping to -349444 . I'll note that the issue does not seem
to be uniquely tied to crtbeginS.o but the
devel/powerpc64-binutils based builds stop teh build before
hitting other examples.)
The code for devel/powerpc64-bintuils has the comment:
/* Look through the reloc flags left by ppc_elf_check_relocs.
Use the old style bss plt if a file makes plt calls
without using the new relocs, and if ld isn't given
--secure-plt and we never see REL16 relocs. */
(I'll show code around that later.)
For something like crtbeginS.o system-clang (from head) ends up with
the likes of the following with no use of any R_PPC_REL16* variants:
Relocation section with addend (.rela.text):
r_offset r_info r_type st_value st_name + r_addend
001c 0d17 R_PPC_LOCAL24PC _GLOBAL_OFFSET_TABLE_ + fffc
0026 060e R_PPC_GOT16 0008 __do_global_dtors_aux.completed
+ 0
0036 0f0e R_PPC_GOT16 __cxa_finalize + 0
0042 100e R_PPC_GOT16 __dso_handle + 0
0048 0f12 R_PPC_PLTREL24 __cxa_finalize + 8000
004e 070e R_PPC_GOT16 0004 __do_global_dtors_aux.p + 0
0062 070e R_PPC_GOT16 0004 __do_global_dtors_aux.p + 0
0086 060e R_PPC_GOT16 0008 __do_global_dtors_aux.completed
+ 0
00ec 0d17 R_PPC_LOCAL24PC _GLOBAL_OFFSET_TABLE_ + fffc
00f6 040e R_PPC_GOT16 __JCR_LIST__ + 0
0106 0e0e R_PPC_GOT16 _Jv_RegisterClasses + 0
0112 040e R_PPC_GOT16 __JCR_LIST__ + 0
Relocation section with addend (.rela.fini):
r_offset r_info r_type st_value st_name + r_addend
0b0a R_PPC_REL24 .text + 0
Relocation section with addend (.rela.init):
r_offset r_info r_type st_value st_name + r_addend
0b0a R_PPC_REL24 .text + d4
Relocation section with addend (.rela.data):
r_offset r_info r_type st_value st_name + r_addend
1001 R_PPC_ADDR32 __dso_handle + 0
0004 0c01 R_PPC_ADDR32 .dtors + 4
It appears that any .o ending up like crtbeginS.o leads to an overall
use of bss-plt instead of secure-lt use (absent an explicit
--secure-plt ). This ends up being tied to ->has_rel16 use.
The code that sets ->has_rel16 = 1 is:
case R_PPC_REL16:
case R_PPC_REL16_LO:
case R_PPC_REL16_HI:
case R_PPC_REL16_HA:
ppc_elf_tdata (abfd)->has_rel16 = 1;
break;
The plt_type = PLT_NEW use when ->plt_type is initially PLT_UNSET
requires ->has_rel16!=0 :
. . .
if (htab->plt_type == PLT_UNSET)
{
struct elf_link_hash_entry *h;
if (htab->params->plt_style == PLT_OLD)
htab->plt_type = PLT_OLD;
else if (info->shared
&& htab->elf.dynamic_sections_created
&& (h = elf_link_hash_lookup (&htab->elf, "_mcount",
FALSE, FALSE, TRUE)) != NULL
&& (h->type == STT_FUNC
|| h->needs_plt)
&& h->ref_regular
&& !(SYMBOL_CALLS_LOCAL (info, h)
|| (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
&& h->root.type == bfd_link_hash_undefweak)))
. . .
else
{
bfd *ibfd;
enum ppc_elf_plt_type plt_type = htab->params->plt_style;
/* Look through the reloc flags left by ppc_elf_check_relocs.
Use the old style bss plt if a file makes plt calls
without using the new relocs, and if ld isn't given
--secure-plt and we never see REL16 relocs. */
if (plt_type == PLT_UNSET)
plt_type = PLT_OLD;
for (ibfd = info->input_bfds; ibfd; ibfd = ibfd->link.next)
if (is_ppc_elf (ibfd))
{
if (ppc_elf_tdata (ibfd)->has_rel16)
plt_type = PLT_NEW;
else if (ppc_elf_tdata (ibfd)->makes_plt_call)
{
plt_type = PLT_OLD;
htab->old_bfd = ibfd;
break;
}
}
htab->plt_type = plt_type;
}
}
if (htab->plt_type == PLT_OLD && htab->params->plt_st
Re: head -r347549 installworld targeting amd64 after debug build: "stand/efi/boot1 (install)" tried to cc ... -o boot1.sym.full ... and got cc: not found
On 2019-Jun-18, at 16:23, Bryan Drewery wrote: > On 6/18/2019 3:55 PM, Mark Millard wrote: >> [I'm back at -r347549 because of other on-going investigations >> that started back then.] >> >> I normally do non-debug -jN builds but had a reason to make >> a debug build for amd64 to be installed and booted (head >> -r347549 ). But it is failing with the below. The >> buildworld did not report and issues in its typescript log >> as far as I found when I looked. >> >> ===> stand/efi/boot1 (install) >> installing DIRS BINDIR >> install -d -m 0755 -o root -g wheel /boot >> cc -target x86_64-unknown-freebsd13.0 >> --sysroot=/usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/tmp >> -B/usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 >> -pipe -Wformat -fshort-wchar -mno-red-zone -nostdinc >> -I/usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa >> -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys >> -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT >> -I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -ffreestanding -mno-mmx >> -mno-sse -mno-avx -mno-avx2 -msoft-float -fPIC -mno-red-zone -I. -DEFI_BOOT1 >> -DEFI_ZFS_BOOT -I/usr/src/stand/efi/include >> -I/usr/src/stand/efi/include/amd64 -I/usr/src/sys/contrib/dev/acpica/include >> -DEFI_UFS_BOOT -I/usr/src/stand/common -fPIC -g -std=gnu99 -Wsystem-headers >> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion >> -Wno-unused-local-t ypedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -nostdlib -Wl,-T/usr/src/stand/efi/loader/arch/amd64/ldscript.amd64,-Bsymbolic,-znotext -shared -Wl,-znocombreloc -Wl,--no-threads -o boot1.sym.full boot1.o self_reloc.o start.o ufs_module.o devpath.o zfs_module.o /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/libefi/libefi.a /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa/libsa.a >> /tmp/install.JSyxbO0g/sh: cc: not found > > cc is purposely not found during install. Yep. I expected that. > The problem is that it is > trying to link during install. That's bad. It should have already done > that during the build. It did. > Some timestamp is wrong and caused a relink. The retry of building from scratch and installing (via DESTDIR back to the messed up partition) did not have the problem. It suggests a race. (The alternate build context happens to have been from the restore of a dump -> restore today of the partition that later had world messed up by the install. Same machine. Both were under Hyper-V, and so on. No likely significant differences.) >> *** Error code 127 >> >> Stop. >> make[6]: stopped in /usr/src/stand/efi/boot1 >> *** Error code 1 >> >> Stop. >> make[5]: stopped in /usr/src/stand/efi >> *** Error code 1 >> >> Stop. >> make[4]: stopped in /usr/src/stand >> *** Error code 1 >> >> Stop. >> make[3]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make[2]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src >> >> Script done, output file is >> /root/sys_typescripts/typescript_make_amd64_debug_clang-amd64-host-2019-06-18:15:16:18 >> >> >> The buildworld produced a stand/efi/boot1/boot1.o that apparently >> finished after stand/efi/boot1/boot1.sym.full and so lead to the >> installation make trying a rebuild, note the 14:59:12 for >> boot1.o.meta vs. the 14:59:11 for boot1.sym.full.meta as >> an example and the list order is via -lTdt : >> >> # ls -lTdt >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1* >> -rw-r--r-- 1 root wheel6228 Jun 18 14:59:12 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.o.meta >> -rw-r--r-- 1 root wheel 43344 Jun 18 14:59:12 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.o >> -rw-r--r-- 1 root wheel2042 Jun 18 14:59:11 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efifat.meta >> -rw-r--r-- 1 root wheel 819200 Jun 18 14:59:11 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efifat >> -rw-r--r-- 1 root wheel1561 Jun 18 14:59:11 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efi.meta >> -rwxr-xr-x 1 root wheel 81920 Jun 18 14:59:11 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efi >> -rw-r--r-- 1 root wheel 841 Jun 18 14:59:11 2019 >> /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.meta >> -rwxr-xr-x 1 root wheel 121416 Jun 18 14:59:11 2019 >
head -r347549 installworld targeting amd64 after debug build: "stand/efi/boot1 (install)" tried to cc ... -o boot1.sym.full ... and got cc: not found
[I'm back at -r347549 because of other on-going investigations that started back then.] I normally do non-debug -jN builds but had a reason to make a debug build for amd64 to be installed and booted (head -r347549 ). But it is failing with the below. The buildworld did not report and issues in its typescript log as far as I found when I looked. ===> stand/efi/boot1 (install) installing DIRS BINDIR install -d -m 0755 -o root -g wheel /boot cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -Wformat -fshort-wchar -mno-red-zone -nostdinc -I/usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT -I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -ffreestanding -mno-mmx -mno-sse -mno-avx -mno-avx2 -msoft-float -fPIC -mno-red-zone -I. -DEFI_BOOT1 -DEFI_ZFS_BOOT -I/usr/src/stand/efi/include -I/usr/src/stand/efi/include/amd64 -I/usr/src/sys/contrib/dev/acpica/include -DEFI_UFS_BOOT -I/usr/src/stand/common -fPIC -g -std=gnu99 -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-type def -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -nostdlib -Wl,-T/usr/src/stand/efi/loader/arch/amd64/ldscript.amd64,-Bsymbolic,-znotext -shared -Wl,-znocombreloc -Wl,--no-threads -o boot1.sym.full boot1.o self_reloc.o start.o ufs_module.o devpath.o zfs_module.o /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/libefi/libefi.a /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa/libsa.a /tmp/install.JSyxbO0g/sh: cc: not found *** Error code 127 Stop. make[6]: stopped in /usr/src/stand/efi/boot1 *** Error code 1 Stop. make[5]: stopped in /usr/src/stand/efi *** Error code 1 Stop. make[4]: stopped in /usr/src/stand *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src Script done, output file is /root/sys_typescripts/typescript_make_amd64_debug_clang-amd64-host-2019-06-18:15:16:18 The buildworld produced a stand/efi/boot1/boot1.o that apparently finished after stand/efi/boot1/boot1.sym.full and so lead to the installation make trying a rebuild, note the 14:59:12 for boot1.o.meta vs. the 14:59:11 for boot1.sym.full.meta as an example and the list order is via -lTdt : # ls -lTdt /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1* -rw-r--r-- 1 root wheel6228 Jun 18 14:59:12 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.o.meta -rw-r--r-- 1 root wheel 43344 Jun 18 14:59:12 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.o -rw-r--r-- 1 root wheel2042 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efifat.meta -rw-r--r-- 1 root wheel 819200 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efifat -rw-r--r-- 1 root wheel1561 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efi.meta -rwxr-xr-x 1 root wheel 81920 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.efi -rw-r--r-- 1 root wheel 841 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.meta -rwxr-xr-x 1 root wheel 121416 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym -rw-r--r-- 1 root wheel 814 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.debug.meta -rwxr-xr-x 1 root wheel 217408 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.debug -rw-r--r-- 1 root wheel3024 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.full.meta -rwxr-xr-x 1 root wheel 325744 Jun 18 14:59:11 2019 /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.full (Hmm. I missed part of a line for that last. Too late now.) The boot1.sym.full.meta shows: # more /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.full.meta # Meta data file /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1/boot1.sym.full.meta CMD cc -target x86_64-un
Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ?
[Looks to me like the ->valid mask only is used for the
last page of the /sbin/init file, not based on the size
and alignment of the data requested for the PT_LOAD.]
On 2019-Jun-11, at 21:53, Mark Millard wrote:
> [The garbage after .got up to the page boundary is
> .comment section strings. The context here is
> targeting 32-bit powerpc via system-clang-8 and
> devel/powerpc64-binutils for buildworld and
> buildkernel . ]
>
> On 2019-Jun-11, at 19:55, Mark Millard wrote:
>
>> [I have confirmed .sbss not being zero'd out and environ
>> thereby starting out non-zero (garbage): a
>> debug.minidump=0 style dump.]
>>
>>> On 2019-Jun-10, at 16:19, Mark Millard wrote:
>>>
>>> . . . (omitted) . . .
>>
>> I used debug.minidump=0 in /boot/loader.conf for
>> cusing a dump for the crash and a libkvm modified
>> enough for my working boot environment to allow me
>> to examine the the memory-image bytes of such a dump,
>> with libkvm used via /usr/local/bin/kgdb . (No support
>> of automatically translating user-space addresses
>> or other such.)
>>
>> For the clang based debug buildworld and debug buildkernel
>> context with /sbin/init having:
>>
>> [16] .got PROGBITS01956ccc 146ccc 10 04 WAX 0 0
>> 4
>> [17] .sbss NOBITS 01956cdc 146cdc b0 00 WA 0 0
>> 4
>> [18] .bss NOBITS 01956dc0 146cdc 02ee28 00 WA 0 0
>> 64
>>
>> I confirmed that .sbss in /sbin/init's address space
>> is not zeroed (so environ is not assigned by handle_argv ).
>> I also confirmed that _start was given a good env value
>> (in %r5) based on where the value was stored on the
>> stack. It is just that the value was not used.
>>
>> The detailed obvious-failure point (crash) can change based
>> on the garbage in the .sbss and, for the build that I used
>> this time, that happened in __je_arean_malloc_hard instead
>> of before _init_tls called _libc_allocate_tls . (I traced
>> the call chain in the dump.)
>>
>>
>> From what I've seen in the dump there seem to be special
>> uses of some values (that also have normal uses, of
>> course):
>>
>> 0xfa5005af: as yet invalid page content.
>> 0x1c20: as yet unassigned user-space-stack memory for /sbin/init.
>>
>> These are the same locations that I previously reported as
>> showing up in the DSI read trap reports for /sbin/init failing.
>> The specific build here failed with a different value.
>>
>> For reference relative to libkvm:
>>
>> # svnlite diff /usr/src/lib/libkvm/
>> Index: /usr/src/lib/libkvm/kvm_powerpc.c
>> ===
>> --- /usr/src/lib/libkvm/kvm_powerpc.c(revision 347549)
>> +++ /usr/src/lib/libkvm/kvm_powerpc.c(working copy)
>> @@ -211,6 +211,53 @@
>> if (be32toh(vm->ph->p_paddr) == 0x)
>> return ((int)powerpc_va2off(kd, va, ofs));
>>
>> +// HACK in something for what I observe in
>> +// a debug.minidump=0 vmcore.* for 32-bit powerpc
>> +//
>> +if ( be32toh(vm->ph->p_vaddr) == 0x
>> + && be32toh(vm->ph->p_paddr) == 0
>> + && be16toh(vm->eh->e_phnum) == 1
>> + ) {
>> +// Presumes p_memsz is either unsigned
>> +// 32-bit or is 64-bit, same for va .
>> +
>> +if (be32toh(vm->ph->p_memsz) <= va)
>> +return 0; // Like powerpc_va2off
>> +
>> +// If ofs was (signed) 32-bit there
>> +// would be a problem for sufficiently
>> +// large postive memsz's and va's
>> +// near the end --because of p_offset
>> +// and dmphdrsz causing overflow/wrapping
>> +// for some large va values.
>> +// Presumes 64-bit ofs for such cases.
>> +// Also presumes dmphdrsz+p_offset
>> +// is non-negative so that small
>> +// non-negative va values have no
>> +// problems with ofs going negative.
>> +
>> +*ofs =vm->dmphdrsz
>> ++ be32toh(vm->ph->p_offset)
>> ++ va;
>> +
>> +// The normal return value overflows/wraps
>> +// for p_memsz == 0x8000u when va == 0 .
>> +// Avoid this by depending on calling code's
>> +// loop for sufficiently large cases.
>> +// This code presumes p_memsz/2 <= MAX_INT .
>> +// 32-bit powerpc FreeBSD does not allow
>> +// using more than 2 GiBytes of RAM but
>> +// does allow using 2 GiBytes on 64-bit
>> +// hardware.
>> +//
>> +if ( (int)be32toh(vm->ph->p_memsz) < 0
>> + && va < be32toh(vm->ph->p_memsz)/2
>> + )
>> +return be32toh(vm->ph->p_memsz)/2;
>> +
>> +return be32toh(vm->ph->p_memsz) - va;
>> +}
>> +
>> _kvm_err(kd, kd->program, "Raw corefile not supported");
>> return (0);
>> }
>> Index: /usr
Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ?
[The garbage after .got up to the page boundary is
.comment section strings. The context here is
targeting 32-bit powerpc via system-clang-8 and
devel/powerpc64-binutils for buildworld and
buildkernel . ]
On 2019-Jun-11, at 19:55, Mark Millard wrote:
> [I have confirmed .sbss not being zero'd out and environ
> thereby starting out non-zero (garbage): a
> debug.minidump=0 style dump.]
>
>> On 2019-Jun-10, at 16:19, Mark Millard wrote:
>>
>> . . . (omitted) . . .
>
> I used debug.minidump=0 in /boot/loader.conf for
> cusing a dump for the crash and a libkvm modified
> enough for my working boot environment to allow me
> to examine the the memory-image bytes of such a dump,
> with libkvm used via /usr/local/bin/kgdb . (No support
> of automatically translating user-space addresses
> or other such.)
>
> For the clang based debug buildworld and debug buildkernel
> context with /sbin/init having:
>
> [16] .got PROGBITS01956ccc 146ccc 10 04 WAX 0 0
> 4
> [17] .sbss NOBITS 01956cdc 146cdc b0 00 WA 0 0
> 4
> [18] .bss NOBITS 01956dc0 146cdc 02ee28 00 WA 0 0
> 64
>
> I confirmed that .sbss in /sbin/init's address space
> is not zeroed (so environ is not assigned by handle_argv ).
> I also confirmed that _start was given a good env value
> (in %r5) based on where the value was stored on the
> stack. It is just that the value was not used.
>
> The detailed obvious-failure point (crash) can change based
> on the garbage in the .sbss and, for the build that I used
> this time, that happened in __je_arean_malloc_hard instead
> of before _init_tls called _libc_allocate_tls . (I traced
> the call chain in the dump.)
>
>
> From what I've seen in the dump there seem to be special
> uses of some values (that also have normal uses, of
> course):
>
> 0xfa5005af: as yet invalid page content.
> 0x1c20: as yet unassigned user-space-stack memory for /sbin/init.
>
> These are the same locations that I previously reported as
> showing up in the DSI read trap reports for /sbin/init failing.
> The specific build here failed with a different value.
>
> For reference relative to libkvm:
>
> # svnlite diff /usr/src/lib/libkvm/
> Index: /usr/src/lib/libkvm/kvm_powerpc.c
> ===
> --- /usr/src/lib/libkvm/kvm_powerpc.c (revision 347549)
> +++ /usr/src/lib/libkvm/kvm_powerpc.c (working copy)
> @@ -211,6 +211,53 @@
> if (be32toh(vm->ph->p_paddr) == 0x)
> return ((int)powerpc_va2off(kd, va, ofs));
>
> + // HACK in something for what I observe in
> + // a debug.minidump=0 vmcore.* for 32-bit powerpc
> + //
> + if ( be32toh(vm->ph->p_vaddr) == 0x
> +&& be32toh(vm->ph->p_paddr) == 0
> +&& be16toh(vm->eh->e_phnum) == 1
> +) {
> + // Presumes p_memsz is either unsigned
> + // 32-bit or is 64-bit, same for va .
> +
> + if (be32toh(vm->ph->p_memsz) <= va)
> + return 0; // Like powerpc_va2off
> +
> + // If ofs was (signed) 32-bit there
> + // would be a problem for sufficiently
> + // large postive memsz's and va's
> + // near the end --because of p_offset
> + // and dmphdrsz causing overflow/wrapping
> + // for some large va values.
> + // Presumes 64-bit ofs for such cases.
> + // Also presumes dmphdrsz+p_offset
> + // is non-negative so that small
> + // non-negative va values have no
> + // problems with ofs going negative.
> +
> + *ofs =vm->dmphdrsz
> + + be32toh(vm->ph->p_offset)
> + + va;
> +
> + // The normal return value overflows/wraps
> + // for p_memsz == 0x8000u when va == 0 .
> + // Avoid this by depending on calling code's
> + // loop for sufficiently large cases.
> + // This code presumes p_memsz/2 <= MAX_INT .
> + // 32-bit powerpc FreeBSD does not allow
> + // using more than 2 GiBytes of RAM but
> + // does allow using 2 GiBytes on 64-bit
> + // hardware.
> + //
> + if ( (int)be32toh(vm->ph->p_memsz) < 0
> +&& va < be32toh(vm->ph->p_memsz)/2
> +)
> + return be32toh(vm->ph->p_memsz)/2;
> +
> + return be32toh(vm->ph->p_memsz) - va;
> + }
> +
> _kvm_err(kd, kd->program, "Raw corefile not supported");
> return (0);
> }
> Index: /usr/src/lib/libkvm/kvm_private.c
> ===
> --- /usr/src/lib/libkvm/kvm_private.c (revision 347549)
> +++ /usr/src/lib/libkvm/kvm_private.c (working copy)
> @@ -131,7 +131,9 @@
> {
>
> return (kd->nlehdr.e_ident[EI_CLASS] == class &&
> -
crash of 32-bit powerpc -r347549 kernel built via system-clang-8, _init_tls is where the initial DIAGNOSTICS-reported SIGSEGV happens
The failure is related to *sp++ in the
below source code from lib/libc/gen/tls.c .
extern char **environ;
void
_init_tls(void)
{
#ifndef PIC
Elf_Addr *sp;
Elf_Auxinfo *aux, *auxp;
Elf_Phdr *phdr;
size_t phent, phnum;
int i;
void *tls;
sp = (Elf_Addr *) environ;
while (*sp++ != 0)
;
. . .
system-clang-8 produced the following
code in /sbin/init :
01812f50 <_init_tls> mflrr0
01812f54 <_init_tls+0x4> stw r0,4(r1)
01812f58 <_init_tls+0x8> stwur1,-16(r1)
01812f5c <_init_tls+0xc> stw r31,12(r1)
01812f60 <_init_tls+0x10> mr r31,r1
01812f64 <_init_tls+0x14> lis r3,404
01812f68 <_init_tls+0x18> lwz r4,-28276(r3) Note: r4=*environ
01812f6c <_init_tls+0x1c> li r5,0
01812f70 <_init_tls+0x20> addir3,r4,-4
01812f74 <_init_tls+0x24> lwzur7,4(r3) fails here
01812f78 <_init_tls+0x28> mr r6,r5
01812f7c <_init_tls+0x2c> addir5,r5,1
01812f80 <_init_tls+0x30> cmplwi r7,0
01812f84 <_init_tls+0x34> bne+01812f74 <_init_tls+0x24>
. . .
readelf -asW shows environ as:
2652: 0193918c 4 OBJECT GLOBAL DEFAULT 17 environ
MAJOR CONCLUSION (so far): It appears that the values
found by the sp++ are strange so *sp++ gets the SIGSEGV.
The:
01812f64 <_init_tls+0x14> lis r3,404
01812f68 <_init_tls+0x18> lwz r4,-28276(r3)
does match up: 0x193918c==(404<<16)-28276 .
It looks like the Elf_Addr value itself is strange
when the SIGSEGV's happen.
The evidence for where the failure point is was:
KDB: enter p_pid 1 got signal 11
[ thread pid 1 tid 12 ]
Stopped at kdb_enter+0x74: addi r3,r0,0x0
db> bt
Tracing pid 1 tid 12 td 0x1506ae0
0xd6b7c950: at cursig+0x55c
0xd6b7ca10: at ast+0x508
0xd6b7ca40: user DSI read trap @ 0x1c20 by 0x1812f74: srr1=0xd032
r1=0xde90 cr=0x2000 xer=0 ctr=0 sr=0x4000
frame=0xd6b7ca48
db>
The "trap @" value can vary, such as instead being 0xfa5005af .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: crash of 32-bit powerpc -r347549 kernel built via system-clang-8 (crash is while trying to mount the root file system) [debug kernel case: code generation error] [I was wrong]
[I misanalysed the code. Sorry for the noise.]
On 2019-Jun-5, at 14:17, Mark Millard wrote:
> [This is from my experiments with more modern toolchains than
> normally/offocially used, specifically for 32-bit powerpc this
> time.]
>
> On 2019-Jun-5, at 01:35, Mark Millard wrote:
>
>> On 2019-Jun-3, at 19:40, Mark Millard wrote:
>>
>>> On 2019-Jun-3, at 17:24, Mark Millard wrote:
>>>
I tried (cross) building a 32-bit powerpc kernel and world (non-debug)
with system-clang (on amd64) and use of devel/powerpc64-binutils . The
installed kernel panics trying to mount the root file system.
FYI: Typed from picture of screen . . .
Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]...
panic: getnewbuf_empty: Locked buf 0xd280 on free queue.
. . .
0xd6919080: at kdb_backtrace+0x64
0xd69190e0: at vpanic+0x200
0xd6919150: at panic+0x50
0xd6919190: at getnewbuf+0x594
0xd69191f0: at getblkx+0x540
0xd69192a0: at breadn_flags+0x90
0xd69192f0: at ffs_use_bread+0x9c
0xd6919330: at readsuper+0x68
0xd6919370: at ffs_sbget+0xcc
0xd69193c0: at ffs_mount+0x18b8
0xd69194f0: at vfs_domount+0xa74
0xd69196a0: at vfs_donmount+0x944
0xd6919700: at kernel_mount+0x64
0xd6919740: at parse_mount+0x52c
0xd6919840: at vfs_mountroot+0x71c
0xd69199b0: at start_init+0x44
0xd6919a10: at fork_exit_0xcc
0xd6919a40: at fork_trampoline+0xc
KDB: enter panic
[ thread pid 1 tid 12 ]
Stopped at kdb_enter+0x74: addi r3,r0,0x0
This reproduces with each boot attempt.
Replacing the kernel with one built via gcc 4.2.1 and booting
the result does not panic.
FYI for the context of the panic call:
/usr/src/sys/kern/vfs_bio.c :
static struct buf *
buf_alloc(struct bufdomain *bd)
{
struct buf *bp;
int freebufs;
/*
* We can only run out of bufs in the buf zone if the average buf
* is less than BKVASIZE. In this case the actual wait/block will
* come from buf_reycle() failing to flush one of these small bufs.
*/
bp = NULL;
freebufs = atomic_fetchadd_int(&bd->bd_freebuffers, -1);
if (freebufs > 0)
bp = uma_zalloc(buf_zone, M_NOWAIT);
if (bp == NULL) {
atomic_add_int(&bd->bd_freebuffers, 1);
bufspace_daemon_wakeup(bd);
counter_u64_add(numbufallocfails, 1);
return (NULL);
}
/*
* Wake-up the bufspace daemon on transition below threshold.
*/
if (freebufs == bd->bd_lofreebuffers)
bufspace_daemon_wakeup(bd);
if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT, NULL) != 0)
panic("getnewbuf_empty: Locked buf %p on free queue.", bp);
>>>
>>>
>>> I tried making a debug kernel build via system-clang-8. It
>>> reports differently but still during getnewbuf being active
>>> on the stack (again typed from a picture):
>>>
>>> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]...
>>> . . . (ignore witness/diagnostic warnings) . . .
>>> panic: bq_remove: Locked buf 0xd2a0 not on a queue.
>>> . . .
>>> 0xd6b7bfd0: at kdb_backtrace+0x64
>>> 0xd6b7c030: at vpanic+0x200
>>> 0xd6b7c0a0: at panic+0x50
>>> 0xd6b7c0e0: at bq_remove+01e0
>>> 0xd6b7c100: at buf_import+0x8c
>>> 0xd6b7c130: at uma_zalloc_arg+0x544
>>> 0xd6b7c190: at getnewbuf+0x380
>>> 0xd6b7c1f0: at getblkx+0x620
>>> 0xd6b7c290: at breadn_flags+0x90
>>> 0xd6b7c2e0: at ffs_use_bread+0xa8
>>> 0xd6b7c320: at readsuper+0x68
>>> 0xd6b7c360: at ffs_sbget+0xcc
>>> 0xd6b7c3b0: at ffs_mount+0xefc
>>> 0xd6b7c4e0: at vfs_domount+0xa754
>>> 0xd6b7c690: at vfs_donmount+0x78c
>>> 0xd6b7c6f0: at kernel_mount+0x7c
>>> 0xd6b7c730: at parse_mount+0x52c
>>> 0xd6b7c830: at vfs_mountroot+0x660
>>> 0xd6b7c9a0: at start_init+0x4c
>>> 0xd6b7ca10: at fork_exit_0xb0
>>> 0xd6b7ca40: at fork_trampoline+0xc
>>>
>>> /usr/src/sys/kern/vfs_bio.c :
>>>
>>> static void
>>> bq_remove(struct bufqueue *bq, struct buf *bp)
>>> {
>>>
>>> CTR3(KTR_BUF, "bq_remove(%p) vp %p flags %X",
>>> bp, bp->b_vp, bp->b_flags);
>>> KASSERT(bp->b_qindex != QUEUE_NONE,
>>> ("bq_remove: buffer %p not on a queue.", bp));
>>> . . .
>>>
>>> For reference:
>>>
>>> static int
>>> buf_import(void *arg, void **store, int cnt, int domain, int flags)
>>> {
>>> struct buf *bp;
>>> int i;
>>>
>>> BQ_LOCK(&bqempty);
>>> for (i = 0; i < cnt; i++) {
>>> bp = TAILQ_FIRST(&bqempty.bq_queue);
>>> if (bp == NULL)
>>> break;
>>> bq_remove(&bqempty, bp);
>>> store[i] = bp;
>>> }
>>> BQ_UNLOCK(&bqempty);
>>>
>>> return (i);
>>> }
>>>
>>>
>>
>> I tried building the debug kernel with KTR for KTR_BUF.
>> Inst
Re: crash of 32-bit powerpc -r347549 kernel built via system-clang-8 (crash is while trying to mount the root file system) [debug kernel case: code generation error]
[This is from my experiments with more modern toolchains than
normally/offocially used, specifically for 32-bit powerpc this
time.]
On 2019-Jun-5, at 01:35, Mark Millard wrote:
> On 2019-Jun-3, at 19:40, Mark Millard wrote:
>
>> On 2019-Jun-3, at 17:24, Mark Millard wrote:
>>
>>> I tried (cross) building a 32-bit powerpc kernel and world (non-debug)
>>> with system-clang (on amd64) and use of devel/powerpc64-binutils . The
>>> installed kernel panics trying to mount the root file system.
>>>
>>> FYI: Typed from picture of screen . . .
>>>
>>> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]...
>>> panic: getnewbuf_empty: Locked buf 0xd280 on free queue.
>>> . . .
>>> 0xd6919080: at kdb_backtrace+0x64
>>> 0xd69190e0: at vpanic+0x200
>>> 0xd6919150: at panic+0x50
>>> 0xd6919190: at getnewbuf+0x594
>>> 0xd69191f0: at getblkx+0x540
>>> 0xd69192a0: at breadn_flags+0x90
>>> 0xd69192f0: at ffs_use_bread+0x9c
>>> 0xd6919330: at readsuper+0x68
>>> 0xd6919370: at ffs_sbget+0xcc
>>> 0xd69193c0: at ffs_mount+0x18b8
>>> 0xd69194f0: at vfs_domount+0xa74
>>> 0xd69196a0: at vfs_donmount+0x944
>>> 0xd6919700: at kernel_mount+0x64
>>> 0xd6919740: at parse_mount+0x52c
>>> 0xd6919840: at vfs_mountroot+0x71c
>>> 0xd69199b0: at start_init+0x44
>>> 0xd6919a10: at fork_exit_0xcc
>>> 0xd6919a40: at fork_trampoline+0xc
>>> KDB: enter panic
>>> [ thread pid 1 tid 12 ]
>>> Stopped at kdb_enter+0x74: addi r3,r0,0x0
>>>
>>> This reproduces with each boot attempt.
>>>
>>> Replacing the kernel with one built via gcc 4.2.1 and booting
>>> the result does not panic.
>>>
>>>
>>> FYI for the context of the panic call:
>>>
>>> /usr/src/sys/kern/vfs_bio.c :
>>>
>>> static struct buf *
>>> buf_alloc(struct bufdomain *bd)
>>> {
>>> struct buf *bp;
>>> int freebufs;
>>>
>>> /*
>>> * We can only run out of bufs in the buf zone if the average buf
>>> * is less than BKVASIZE. In this case the actual wait/block will
>>> * come from buf_reycle() failing to flush one of these small bufs.
>>> */
>>> bp = NULL;
>>> freebufs = atomic_fetchadd_int(&bd->bd_freebuffers, -1);
>>> if (freebufs > 0)
>>> bp = uma_zalloc(buf_zone, M_NOWAIT);
>>> if (bp == NULL) {
>>> atomic_add_int(&bd->bd_freebuffers, 1);
>>> bufspace_daemon_wakeup(bd);
>>> counter_u64_add(numbufallocfails, 1);
>>> return (NULL);
>>> }
>>> /*
>>> * Wake-up the bufspace daemon on transition below threshold.
>>> */
>>> if (freebufs == bd->bd_lofreebuffers)
>>> bufspace_daemon_wakeup(bd);
>>>
>>> if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT, NULL) != 0)
>>> panic("getnewbuf_empty: Locked buf %p on free queue.", bp);
>>
>>
>> I tried making a debug kernel build via system-clang-8. It
>> reports differently but still during getnewbuf being active
>> on the stack (again typed from a picture):
>>
>> Trying to mount root from ufs:/dev/ufs/FBSDG4Srootfs [rw,noatime]...
>> . . . (ignore witness/diagnostic warnings) . . .
>> panic: bq_remove: Locked buf 0xd2a0 not on a queue.
>> . . .
>> 0xd6b7bfd0: at kdb_backtrace+0x64
>> 0xd6b7c030: at vpanic+0x200
>> 0xd6b7c0a0: at panic+0x50
>> 0xd6b7c0e0: at bq_remove+01e0
>> 0xd6b7c100: at buf_import+0x8c
>> 0xd6b7c130: at uma_zalloc_arg+0x544
>> 0xd6b7c190: at getnewbuf+0x380
>> 0xd6b7c1f0: at getblkx+0x620
>> 0xd6b7c290: at breadn_flags+0x90
>> 0xd6b7c2e0: at ffs_use_bread+0xa8
>> 0xd6b7c320: at readsuper+0x68
>> 0xd6b7c360: at ffs_sbget+0xcc
>> 0xd6b7c3b0: at ffs_mount+0xefc
>> 0xd6b7c4e0: at vfs_domount+0xa754
>> 0xd6b7c690: at vfs_donmount+0x78c
>> 0xd6b7c6f0: at kernel_mount+0x7c
>> 0xd6b7c730: at parse_mount+0x52c
>> 0xd6b7c830: at vfs_mountroot+0x660
>> 0xd6b7c9a0: at start_init+0x4c
>> 0xd6b7ca10: at fork_exit_0xb0
>> 0xd6b7ca40: at fork_trampoline+0xc
>>
>> /usr/src/sys/kern/vfs_bio.c :
>>
>> static void
>> bq_remove(struct bufqueue *bq, struct buf *bp)
>> {
>>
>> CTR3(KTR_BUF, "bq_remove(%p) vp %p flags %X",
>> bp, bp->b_vp, bp->b_flags);
>> KASSERT(bp->b_qindex != QUEUE_NONE,
>> ("bq_remove: buffer %p not on a queue.", bp));
>> . . .
>>
>> For reference:
>>
>> static int
>> buf_import(void *arg, void **store, int cnt, int domain, int flags)
>> {
>> struct buf *bp;
>> int i;
>>
>> BQ_LOCK(&bqempty);
>> for (i = 0; i < cnt; i++) {
>> bp = TAILQ_FIRST(&bqempty.bq_queue);
>> if (bp == NULL)
>> break;
>> bq_remove(&bqempty, bp);
>> store[i] = bp;
>> }
>> BQ_UNLOCK(&bqempty);
>>
>> return (i);
>> }
>>
>>
>
> I tried building the debug kernel with KTR for KTR_BUF.
> Installing and booting the result did not panic. Manually
> forcing getting to ddb> soon enough and doing "show ktr"
> did show a bq_remove for 0xd2a0 (and later activity).
>
> From the looks of the KTR_BUF CT
