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 &g
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
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 a
powerpc (32-bit): error: statement with no effect at sys/net/iflib.c:1258 : #define iflib_netmap_txq_init(ctx, txq) (0)
.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/sys/conf/kern.mk' .PATH='. /usr/src/sys/modules/iflib /usr/src/sys/net /usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG' 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"
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"
: "=" (ret), "=m" (*p), "+" (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
werpc/usr.bin/gh-bc' 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"
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)
--infodir=/usr/local/share/info/gcc9 --build=powerpc-portbld-freebsd13.0 Thread model: posix gcc version 9.2.0 (FreeBSD Ports Collection) # powerpc-unknown-freebsd13.0-g++9 -v Using built-in specs. COLLECT_GCC=powerpc-unknown-freebsd13.0-g++9 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-unknown-freebsd13.0/9.2.0/lto-wrapper Target: powerpc-unknown-freebsd13.0 Configured with: /wrkdirs/usr/ports/devel/freebsd-gcc9/work-powerpc/gcc-9.2.0/configure --target=powerpc-unknown-freebsd13.0 --disable-nls --enable-languages=c,c++ --enable-gnu-indirect-function --enable-initfini-array --program-prefix=powerpc-unknown-freebsd13.0- --program-suffix=9 --without-headers --with-gmp=/usr/local --with-pkgversion='FreeBSD Ports Collection for powerpc' --with-system-zlib --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/ --with-as=/usr/local/bin/powerpc-unknown-freebsd13.0-as --with-ld=/usr/local/bin/powerpc-unknown-freebsd13.0-ld --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=powerpc-unknown-freebsd13.0 Thread model: posix gcc version 9.2.0 (FreeBSD Ports Collection for powerpc) # c++ -v FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin === 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"
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 | eg
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 491
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
000 183a 04fc .got2 + 800a 183e 04fa .got2 + 800e . . . Symbol table (.symtab) contains 62 entries: Num:Value Size TypeBind Vis Ndx Name . . . 43: 1112 FUNCLOCAL DEFAULT1 vaccess_acl_nfs4 44: 0458 840 FUNCLOCAL DEFAULT1 acl_nfs4_sync_mode_from_acl 45: 181c 248 FUNCLOCAL DEFAULT1 acl_nfs4_check === 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/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
WITHOUT_LLDB=
#
WITH_BOOT=
#
# Fails to build because of forced bss-plt use.
WITHOUT_LIB32=
#
LOADER_DEFAULT_INTERP=4th
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
#WERROR=
MALLOC_PRODUCTION=
#
# Avoid stripping but do not control host -g status as well:
DEBUG_FLAGS+=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#XCFLAGS+= -gdwarf-2
#
# For TO (so-called "cross") stages . . .
# So-called-cross via freebsd-gcc${GCCVERSION}@${TO_TYPE}
# TOOLS_TO_TYPE based on freebsd-gcc${GCCVERSION}@${TO_TYPE} related binutils.
. .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc${GCCVERSION}
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc${GCCVERSION}
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++${GCCVERSION}
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp${GCCVERSION}
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/size
#NO-SUCH:
XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
By contrast, cross-building powerpc64 using system-clang
and devel/binutils@powerpc64 ran to completion, as did
the default system-clang/lld use.
Using ELFv2 for devel/freebsd-gcc9 did avoid the
internal plt template error report that I got
earlier when targeting a ELFv1 context.
32-bit powerpc side note:
For 32-bit powerpc, the only combination to complete
buildworld buildkernel was system-clang with
devel/binutils@powerpc . The default system linker
failed with acl_nfs4.kld(.text+0x234): R_PPC_PLTREL24
reloc against local symbol. Using
devel/freebsd-gcc9@powerpc with devel/binutils@powerpc
resulted in forced bss-plt use stopping the 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"
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
x11-toolkits/qt5-gui build on/for Cortex-A7 ( head -r356109 ) failed with: unable to execute command: Executable "as" doesn't exist
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 9.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf Thread model: posix InstalledDir: /usr/bin # 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: 520539 Node Kind: directory Schedule: normal Last Changed Author: ler Last Changed Rev: 520539 Last Changed Date: 2019-12-20 18:01:52 -0800 (Fri, 20 Dec 2019) === 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/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
s/devel/gmake drwxr-xr-x 3 root wheel 512 Dec 28 02:04:52 2019 /wrkdirs/usr/ports/ports-mgmt/dialog4ports drwxr-xr-x 3 root wheel 512 Dec 28 02:07:44 2019 /wrkdirs/usr/ports/print/indexinfo (I already had pkg 1.12.0 added.) === 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 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=no
For devel/freebsd-gcc9@powerpc64 and devel/binutils@powerpc64 use: internal compiler error: in rs6000_pltseq_template, at config/rs6000/rs6000.c:21873
/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 (FreeBSD Ports Collection for powerpc64) version 9.2.0 (powerpc64-unknown-freebsd13.0) compiled by GNU C version FreeBSD Clang 9.0.0 (tags/RELEASE_900/final 372316), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-unknown-freebsd13.0/9.2.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-unknown-freebsd13.0/9.2.0/../../../../powerpc64-unknown-freebsd13.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common /usr/src/lib/libc/include /usr/local/lib/gcc/powerpc64-unknown-freebsd13.0/9.2.0/include /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include End of search list. GNU C99 (FreeBSD Ports Collection for powerpc64) version 9.2.0 (powerpc64-unknown-freebsd13.0) compiled by GNU C version FreeBSD Clang 9.0.0 (tags/RELEASE_900/final 372316), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c6b29a72d44037ade47bd096976b7211 during RTL pass: final In file included from /usr/src/lib/csu/powerpc64/crt1.c:56: /usr/src/lib/csu/common/ignore_init.c: In function 'finalizer': /usr/src/lib/csu/common/ignore_init.c:100:1: internal compiler error: in rs6000_pltseq_template, at config/rs6000/rs6000.c:21873 100 | } | ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/csu/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"
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)
)
compiled by GNU C version FreeBSD Clang 9.0.0 (tags/RELEASE_900/final
372316), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version
none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/9.2.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/9.2.0/../../../../powerpc-unknown-freebsd13.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/src/lib/csu/common
/usr/src/lib/libc/include
/usr/src/lib/csu/powerpc
/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/9.2.0/include
/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/include
End of search list.
GNU C99 (FreeBSD Ports Collection for powerpc) version 9.2.0
(powerpc-unknown-freebsd13.0)
compiled by GNU C version FreeBSD Clang 9.0.0 (tags/RELEASE_900/final
372316), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version
none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c272cae35a1ab078596359ed10bcfdea
/usr/src/lib/csu/common/crtbegin.c: In function '__do_global_dtors_aux':
/usr/src/lib/csu/common/crtbegin.c:83:21: warning: array subscript 1 is above
array bounds of 'void (*[1])(void)' [-Warray-bounds]
83 | fn = __DTOR_LIST__[n];
|~^~~
/usr/src/lib/csu/common/crtbegin.c:68:17: note: while referencing
'__DTOR_LIST__'
68 | static crt_func __DTOR_LIST__[] __section(".dtors") __used = {
| ^
/usr/src/lib/csu/common/crtbegin.c: In function 'register_classes':
/usr/src/lib/csu/common/crtbegin.c:114:49: warning: array subscript 0 is above
array bounds of 'void (*[0])(void)' [-Warray-bounds]
114 | if (_Jv_RegisterClasses != NULL && __JCR_LIST__[0] != 0)
| ^~~
/usr/src/lib/csu/common/crtbegin.c:114:49: warning: array subscript 0 is above
array bounds of 'void (*[0])(void)' [-Warray-bounds]
/usr/src/lib/csu/common/crtbegin.c:105:17: note: while referencing
'__JCR_LIST__'
105 | static crt_func __JCR_LIST__[] __section(".jcr") __used = { };
| ^~~~
COMPILER_PATH=/usr/local/powerpc-unknown-freebsd13.0/bin/:/usr/local/libexec/gcc/powerpc-unknown-freebsd13.0/9.2.0/:/usr/local/libexec/gcc/powerpc-unknown-freebsd13.0/9.2.0/:/usr/local/libexec/gcc/pow
erpc-unknown-freebsd13.0/:/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/9.2.0/:/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/:/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/9.2.0/../../../../powerpc
-unknown-freebsd13.0/bin/
LIBRARY_PATH=/usr/local/powerpc-unknown-freebsd13.0/bin/:/usr/local/lib/gcc/powerpc-unknown-freebsd13.0/9.2.0/:/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/
COLLECT_GCC_OPTIONS='-gdwarf-2' '-B'
'/usr/local/powerpc-unknown-freebsd13.0/bin/' '-O2' '-pipe' '-I'
'/usr/src/lib/csu/common' '-I' '/usr/src/lib/libc/include' '-D'
'CRT_IRELOC_SUPPRESS' '-g' '-std=g
nu99' '-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-er
ror=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' '-W
no-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=memse
t-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'
'-I' '/usr/src/lib/csu/powerpc' '-D' 'SHARED' '
-fpic' '-c' '-o' 'crtbeginS.o'
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-tool
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 bt
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/
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"
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 regi
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 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
uot; "-lm" "-lgcc" "--as-needed"
"-lgcc_s" "--no-as-needed" "-lpthread" "-lc" "-lgcc" "--as-needed" "-lgcc_s"
"--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"
Similarly for g++9 which uses "/usr/local/bin/ld" directly:
# g++9 -std=c++17 -pedantic -O3 -pthread -c cpp_thousandslocale.cpp
# g++9 -std=c++17 -pedantic -O3 -pthread -c cpp_clockinfo.cpp
# g++9 -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o cpp_clockinfo.o
-o cpp_clockinfo_main cpp_clockinfo_main.cpp
Again using -### :
# g++9 -### -std=c++17 -pedantic -O3 -pthread cpp_thousandslocale.o
cpp_clockinfo.o -o cpp_clockinfo_main cpp_clockinfo_main.cpp
Using built-in specs.
COLLECT_GCC=g++9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/lto-wrapper
Target: x86_64-portbld-freebsd13.0
Configured with: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.2.0/configure
--enable-multilib --with-build-config=bootstrap-debug --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=x86_64-portbld-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/cc1plus -quiet
cpp_clockinfo_main.cpp -quiet -dumpbase cpp_clockinfo_main.cpp "-mtune=generic"
"-march=x86-64" -auxbase cpp_clockinfo_main -O3 -Wpedantic "-std=c++17" -o
/tmp//ccqXOrjE.s
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/bin/as -o /tmp//ccxktS2W.o /tmp//ccqXOrjE.s
COMPILER_PATH=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freebsd13.0/bin/
LIBRARY_PATH=/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freebsd13.0/lib/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/collect2 -plugin
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/liblto_plugin.so
"-plugin-opt=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/lto-wrapper"
"-plugin-opt=-fresolution=/tmp//ccA61h1w.res"
"-plugin-opt=-pass-through=-lgcc_s" "-plugin-opt=-pass-through=-lgcc"
"-plugin-opt=-pass-through=-lpthread" "-plugin-opt=-pass-through=-lc"
"-plugin-opt=-pass-through=-lgcc_s" "-plugin-opt=-pass-through=-lgcc"
--eh-frame-hdr -m elf_x86_64_fbsd -dynamic-linker /libexec/ld-elf.so.1 -o
cpp_clockinfo_main /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/crtbegin.o
-L/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0
-L/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freebsd13.0/lib
-L/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../..
cpp_thousandslocale.o cpp_clockinfo.o /tmp//ccxktS2W.o "-lstdc++" -lm -lg
cc_s -lgcc -lpthread -lc -lgcc_s -lgcc
/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/crtend.o
/usr/lib/crtn.o
COLLECT_GCC_OPTIONS='-std=c++17' '-Wpedantic' '-O3' '-pthread' '-o'
'cpp_clockinfo_main' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Although here it is less obvious what:
/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/collect2
ends up using. So using truss produced the evidence:
3472: execve("/usr/local/bin/ld",0x800b35180,0x7fffd380) EJUSTRETURN
Again: no use of ${LD} or ${XLD} .
Builds that want to control which linker is used need to avoid
using such commands and instead use ${LD} or ${XLD} or such
explicitly. Many do not do this.
===
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"
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"
STRAP=
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=
#
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_VINTAGE}/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/clang90
XCXX=/usr/local/bin/clang++90
XCPP=/usr/local/bin/clang-cpp90
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${LLVM_VINTAGE}/bin/llvm-as
#XAR=/usr/local/${LLVM_VINTAGE}/bin/llvm-ar
XLD=/usr/local/${LLVM_VINTAGE}/bin/ld
#XNM=/usr/local/${LLVM_VINTAGE}/bin/llvm-nm
XOBJCOPY=/usr/local/${LLVM_VINTAGE}/bin/llvm-objcopy
XOBJDUMP=/usr/local/${LLVM_VINTAGE}/bin/llvm-objdump
#XRANLIB=/usr/local/${LLVM_VINTAGE}/bin/llvm-ranlib
#XSIZE=/usr/local/${LLVM_VINTAGE}/bin/llvm-size
#XSTRINGS=/usr/local/${LLVM_VINTAGE}/bin/llvm-strings
.export XAS
#.export XAR
.export XLD
#.export XNM
.export XOBJCOPY
.export XOBJDUMP
#.export XRANLIB
#.export XSIZE
#.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
# more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
#
# GENERIC -- Custom configuration for the powerpc/powerpc
#
include "GENERIC"
ident GENERICvtsc-NODBG
makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols
nooptions PS3 # Sony Playstation 3
HACK!!! to allow sc
options KDB # Enable kernel debugger support
# For minimum debugger support (stable branch) use:
options KDB_TRACE # Print a stack trace for a panic
options DDB # Enable the kernel debugger
options GDB # HACK!!! ...
options ALT_BREAK_TO_DEBUGGER
options BREAK_TO_DEBUGGER
# Extra stuff:
#optionsVERBOSE_SYSINIT # Enable verbose sysinit messages
#optionsBOOTVERBOSE=1
#optionsBOOTHOWTO=RB_VERBOSE
#optionsKTR
#optionsKTR_MASK=KTR_BUF
##options KTR_CPUMASK=0xF
#optionsKTR_VERBOSE
# 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
# Disable any extra checking for. . .
nooptions DEADLKRES # Enable the deadlock resolver
nooptions INVARIANTS # Enable calls of extra sanity checking
nooptions INVARIANT_SUPPORT # Extra sanity checks of internal
structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect deadlocks and
cycles
nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
nooptions DIAGNOSTIC
nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
# Avoid dynamic loads?
device filemon
device geom_label
device mac_ntpd
# more ~/src.configs/make.conf
CFLAGS.gcc+= -v
LDFLAGS.lld+= -Wl,--no-threads
===
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 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
IX=/usr/local/${LLVM_VINTAGE}/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/clang90
XCXX=/usr/local/bin/clang++90
XCPP=/usr/local/bin/clang-cpp90
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${LLVM_VINTAGE}/bin/llvm-as
XAR=/usr/local/${LLVM_VINTAGE}/bin/llvm-ar
XLD=/usr/local/${LLVM_VINTAGE}/bin/ld
XNM=/usr/local/${LLVM_VINTAGE}/bin/llvm-nm
XOBJCOPY=/usr/local/${LLVM_VINTAGE}/bin/llvm-objcopy
XOBJDUMP=/usr/local/${LLVM_VINTAGE}/bin/llvm-objdump
XRANLIB=/usr/local/${LLVM_VINTAGE}/bin/llvm-ranlib
XSIZE=/usr/local/${LLVM_VINTAGE}/bin/llvm-size
XSTRINGS=/usr/local/${LLVM_VINTAGE}/bin/llvm-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
It may well be that the use of some of llvm-as, llvm-ar,
llvm-nm, llvm-objcopy, llvm-objdump, llvm-ranlib,
llvm-size, and llvm-strings is not intended. But I've
not seen a description of the intent.
(My build with devel/powerpc64-binutils involved
completed just fine.)
For reference, devel/llvm90 here is based on ports head
-r509054 providing rc2 of llvm90.
===
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,
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
>>>>>>>> }
>>>>>>>>
>>>>>>&
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}.")
>>
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()
>>>&g
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
[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
On 2019-Aug-6, at 17:59, 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.
>
> 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 .
(No new material after this point.)
> 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 (0
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 >> compatible with llvm90 later using the libz
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
}
}
htab->plt_type = plt_type;
}
}
if (htab->plt_type == PLT_OLD && htab->params->plt_style == PLT_NEW)
{
if (htab->old_bfd != NULL)
info->callbacks->einfo (_("%P: bss-plt forced due to %B\n"),
htab->old_bfd);
else
info->callbacks->einfo (_("%P: bss-plt forced by profiling\n"));
}
. . .
( ppc_elf_select_plt_layout in .../binutils-2_25_1/bfd/elf32-ppc.c )
For reference: the .meta file for the crtbeginS.o shows
(I split lines for readability):
# Meta data file
/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/gnu/lib/csu/crtbeginS.o.meta
CMD cc \
-target powerpc-unknown-freebsd13.0 \
--sysroot=/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp
\
-B/usr/local/powerpc64-unknown-freebsd13.0/bin/ \
-O2 -pipe \
-B/usr/local/powerpc64-unknown-freebsd13.0/bin/ \
-DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 \
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss \
-fno-asynchronous-unwind-tables -fno-omit-frame-pointer \
-I/usr/src/contrib/gcclibs/include -I/usr/src/contrib/gcc/config \
-I/usr/src/contrib/gcc -I. -I/usr/src/gnu/usr.bin/cc/cc_tools \
-g -std=gnu89-Qunused-arguments\
-g0 -DCRT_BEGIN -DCRTSTUFFS_O -DSHARED -fpic \
-c -o crtbeginS.o /usr/src/contrib/gcc/crtstuff.c
CWD
/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/gnu/lib/csu
So noting is explicitly indicating to use secure-plt.
Doing some exploration with partial coverage of buildkernel via the
old system binutils (that does not abort for the bss-plt issue)
instead of devel/powerpc64-binutils reports more examples . . .
# grep bss-plt
~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd64-host-2019-06-27:01:44:37
| sort -u | more
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crt1.o
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/crtbeginS.o
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(fixdfdi.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(fixsfdi.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatdidf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatdisf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatundidf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(floatundisf.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(moddi3.o)
Using bss-plt due to
/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(umoddi3.o)
Using bss-plt due to accf_http.kld
Using bss-plt due to acl_nfs4.kld
Using bss-plt due to acl_posix1e.kld
Using bss-plt due to if_ae.kld
Using bss-plt due to if_age.kld
Using bss-plt due to reloc.o
The coverage of buildkernel is incomplete because of:
--- agp.ko.full ---
ld: agp.kld(.text+0x37a4): R_PPC_PLTREL24 reloc against local symbol
agp.kld: could not read symbols: Bad value
*** [agp.ko.full] Error code 1
===
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 -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 >
head -r347549 installworld targeting amd64 after debug build: "stand/efi/boot1 (install)" tried to cc ... -o boot1.sym.full ... and got cc: not found
_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- typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments -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 CWD /usr/obj/amd64dbg_clang/amd64.amd64/usr/src/amd64.amd64/stand/efi/boot1 TARGET boot1.sym.full -- command output -- -- filemon acquired metadata -- . . . This bad install hosed the build environment and I'm going to build from a different context and then install from there. We will see if the other -r347549 context has the same sort of problem. === 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: 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 sufficie
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->
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_freebuffers, -1);
>>>> if (freebufs > 0)
>>>> bp = uma_zalloc(buf_zone, M_NOWAIT);
>>>> if (bp == NULL) {
>>>> atomic_add_int(>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+0x
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_freebuffers, -1);
>>> if (freebufs > 0)
>>> bp = uma_zalloc(buf_zone, M_NOWAIT);
>>> if (bp == NULL) {
>>> atomic_add_int(>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",
>&g
Re: powerpc64 system-clang-8 based context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/loca
[I forgot to mention of the combination: gcc and libc++.= On 2019-May-24, at 12:11, Mark Millard wrote: > On 2019-May-24, at 11:25, Mark Linimon wrote: > >> On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain >> wrote: >>> That is no matter what the system compiler is for powerpc64. >>> >>> This lead to the below mixing of libstdc++.so.6 and libc++/libcxxrt . . . >> >> Yeah. This is probably my fault. >> >> We've baked the assumption into ports that "powerpc64 implies gcc in base". >> You're the first person to color outside the lines I think :-) >> >> I'm going to start an internal discussion about what the "real" fix is. >> I consider what we've done in some places to not be the "real" fix because >> they assume _either_ llvm _or_ gcc in base. This would fix your specific >> problem but not the general problem of someone installing both and then >> switching back and forth for testing. > > Plus qt5 is outside the range of gcc 4.2.1 to cover, so for it > a usable "gcc in base" would mean base/gcc or some such substitution. > But base/gcc does not imply any version of libstdc++ is in use either: > same problem as system-clang-8-based if something like lang/gcc8 is > used for qt5. > > Even if libstdc++ was (hypothetically) used, the vintage from > base/gcc or devel/*-gcc sorts of materials would not generally > match lang/gcc8 or whatever compiler:c++11-lib and the like > might default to. > > For the likes of qt5, care must be taken that, for example, > devel/icu and its: > > /usr/local/lib/libicui18n.so.64 > /usr/local/lib/libicuuc.so.64 > > vs. qt5: they must use the same c++ library and vintage. > > Then there are things that really could use gcc 4.2.1 from > base: mixed libstdc++ vintages could result, even if some > port lang/gcc* toolchain is used. > > Definitely a messy context. > > The failing behavior (program crash very early when starting) > was not obviously tied to c++ library mixes being involved. It > would be handy if some stage of building/installing/running > caught the presence of such a bad combination and was explicit > about it. I probably should have mentioned using the likes of base/binutils and base/gcc and ending up with a gcc based system c and c++ but a system libc++ / libcxxrt instead of libstdc++ . This would still make for the odd mix of libc++ / libcxxrt vs. libstdc++ if: /usr/local/lib/libicui18n.so.64 /usr/local/lib/libicuuc.so.64 were built by the system toolchain but qt5-core was built by something like lang/gcc8 . system-clang vs. lang/gcc* need not be the only odd 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: powerpc64 system-clang-8 based context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/loca
On 2019-May-24, at 11:25, Mark Linimon wrote: > On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain > wrote: >> That is no matter what the system compiler is for powerpc64. >> >> This lead to the below mixing of libstdc++.so.6 and libc++/libcxxrt . . . > > Yeah. This is probably my fault. > > We've baked the assumption into ports that "powerpc64 implies gcc in base". > You're the first person to color outside the lines I think :-) > > I'm going to start an internal discussion about what the "real" fix is. > I consider what we've done in some places to not be the "real" fix because > they assume _either_ llvm _or_ gcc in base. This would fix your specific > problem but not the general problem of someone installing both and then > switching back and forth for testing. Plus qt5 is outside the range of gcc 4.2.1 to cover, so for it a usable "gcc in base" would mean base/gcc or some such substitution. But base/gcc does not imply any version of libstdc++ is in use either: same problem as system-clang-8-based if something like lang/gcc8 is used for qt5. Even if libstdc++ was (hypothetically) used, the vintage from base/gcc or devel/*-gcc sorts of materials would not generally match lang/gcc8 or whatever compiler:c++11-lib and the like might default to. For the likes of qt5, care must be taken that, for example, devel/icu and its: /usr/local/lib/libicui18n.so.64 /usr/local/lib/libicuuc.so.64 vs. qt5: they must use the same c++ library and vintage. Then there are things that really could use gcc 4.2.1 from base: mixed libstdc++ vintages could result, even if some port lang/gcc* toolchain is used. Definitely a messy context. The failing behavior (program crash very early when starting) was not obviously tied to c++ library mixes being involved. It would be handy if some stage of building/installing/running caught the presence of such a bad combination and was explicit about 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: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"
On 2019-May-24, at 00:10, Ralf Wenk wrote: > On 2019-05-23, at 12:31 -0700, Mark Millard wrote: >> On 2019-May-23, at 11:47, Jan Beich wrote: >> >>> Mark Millard writes: >>> >>>> Unfortunately poudiere bulk tar archives of failures do not >>>> catch the /tmp/* material from: >>>> >>>> cc: error: unable to execute command: Abort trap (core dumped) >>>> cc: error: clang frontend command failed due to signal (use -v to see >>>> invocation) >>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM >>>> 8.0.0) >>>> Target: powerpc64-unknown-freebsd13.0 >>>> Thread model: posix >>>> InstalledDir: /usr/bin >>> >>> Do you have the build log? Maybe it's possible to reproduce simply by adding >>> -target powerpc64-unknown-freebsd13.0 while cross-building that particular >>> file >>> using otherwise the same command line options as native build. >> >> I have expanded the poudriere bulk's tar of the failure and rerun the >> command from there. The problem reproduced: >> >> # ls -lTdt /tmp/nir_constant_expressions-9b094e.* >> -rw-r--r-- 1 root wheel11069 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.sh >> -rw-r--r-- 1 root wheel 1951892 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.c >> >> >> So I gzip'd the .c and created: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082 >> >> with the two files as 2 attachments. > > This looks familiar to me. Is the kernel you are using at r348115 or newer? No, based on head -r347549 : # uname -apKU FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r347549M: Wed May 22 15:14:43 PDT 2019 markmi@FBSDG5L:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300025 1300025 > r348115 triggers such kind of "unable to execute" compiler errors on my > system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238084 I've had no troubles with buildworld or buildkernel. "Unable to execute" is very generic, meaning little more than did-not-finish for whatever reason. In my case it did not finish because: assert(!TLI.isOperationLegalOrCustom(N->getOpcode(), WideVecVT) && "Target supports vector op, but scalar requires expansion?"); failed the test and assert called abort, whihc in turn sent a SIGABRT to the process. Nothing about this suggests a kernel issue. It is more likely a error in handling code generation related to powerpc64 vector operations. I used the core file produced to get the backtrace via gdb: Core was generated by `/usr/bin/cc -cc1 -triple powerpc64-unknown-freebsd13.0 -emit-obj -disable-free -'. Program terminated with signal SIGABRT, Aborted. #0 .__sys_thr_kill () at thr_kill.S:3 3 RSYSCALL(thr_kill) (gdb) bt #0 .__sys_thr_kill () at thr_kill.S:3 #1 0x133072d0 in __raise (s=330578472) at /usr/src/lib/libc/gen/raise.c:52 #2 0x132c7898 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 #3 0x132f6c64 in __assert (func=, file=, line=, failedexpr=) at /usr/src/lib/libc/gen/assert.c:51 #4 0x130f7c18 in WidenVectorResult () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:2531 #5 0x12ad91f0 in run () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:281 #6 0x12adfa5c in LegalizeTypes () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1115 #7 0x1297ebb4 in CodeGenAndEmitDAG () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:776 #8 0x00001297e114 in SelectBasicBlock () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:669 #9 0x1297cbc4 in SelectAllBasicBlocks () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1784 #10 0x in ?? () But I build with debug symbols generally, even for optimized builds. === 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 system-clang-8 based context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/li
[I adjusted the Subject line to give more context.] [/usr/local/lib/qt5/bin/qlalr and /usr/local/lib/qt5/libQt5Core.so.5 overall use each of the following (somewhat indirectly) in my system-clang-8-based powerpc64 context: /usr/local/lib/gcc8/libstdc++.so.6 /usr/lib/libc++.so.1 /lib/libcxxrt.so.1 ] On 2019-May-23, at 21:09, Mark Millard wrote: [Merely adding the extra instruction was not the right idea for what the problem is.] On 2019-May-23, at 20:10, Mark Millard wrote: > [I tried rebuilding things based on a full-bootstrap > build of lang/gcc8 instead. It made no difference.] > > On 2019-May-23, at 14:17, Mark Millard wrote: > >> [It looks like code generation missed a level of indirection >> to me.] >> >>> On 2019-May-23, at 13:46, Mark Millard wrote: >>> >>> [I should have listed uname -apKU output and such.] >>> >>> On 2019-May-23, at 13:21, Mark Millard wrote: >>> >>>> The poudriere bulk run that tried to build x11-toolkits/qt5-declarative >>>> got: >>>> >>>> --- qqmljsgrammar.cpp --- >>>> /usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g >>>> Segmentation fault (core dumped) >>>> *** [qqmljsgrammar.cpp] Error code 139 >>>> >>>> make[3]: stopped in >>>> /wrkdirs/usr/ports/x11-toolkits/qt5-declarative/work/qtdeclarative-everywhere-src-5.12.2/src/qml >>>> 1 error >>>> >>>> Installing qt5-core and manually running under gdb from >>>> an expansion of the bulk's tar of the failure, I was able >>>> to get a backtrace: >>>> >>>> (gdb) run --no-debug --qt parser/qqmljs.g >>>> Starting program: /usr/local/bin/qlalr --no-debug --qt parser/qqmljs.g >>>> process 26823 is executing new program: /usr/local/lib/qt5/bin/qlalr >>>> . . . (text about auto-loading has been declined and such) . . . >>>> Program received signal SIGSEGV, Segmentation fault. >>>> 0x000810a96be0 in std::type_info::~type_info() () from >>>> /usr/local/lib/gcc8/libstdc++.so.6 >>>> (gdb) bt >>>> #0 0x000810a96be0 in std::type_info::~type_info() () from >>>> /usr/local/lib/gcc8/libstdc++.so.6 >>>> #1 0x00081092152c in __cxxabiv1::__dynamic_cast (src_ptr=0x810ab57d0 >>>> <(anonymous namespace)::ctype_c>, src_type=0x810a8eaa0 >>> std::locale::facet>, >>>> dst_type=0x810a8fb18 >, src2dst=0) at >>>> /wrkdirs/usr/ports/lang/gcc8/work/gcc-8.3.0/libstdc++-v3/libsupc++/dyncast.cc:71 >>>> #2 0x0008109df908 in std::has_facet > (__loc=...) at >>>> /wrkdirs/usr/ports/lang/gcc8/work/.build/powerpc64-portbld-freebsd13.0/libstdc++-v3/include/bits/locale_classes.tcc:104 >>>> #3 0x0008109cb474 in std::basic_ios >>>> >::_M_cache_locale (this=0x810ab48c8 , __loc=...) >>>> at >>>> /wrkdirs/usr/ports/lang/gcc8/work/.build/powerpc64-portbld-freebsd13.0/libstdc++-v3/include/bits/basic_ios.tcc:157 >>>> #4 0x0008109cbad0 in std::basic_ios >>>> >::init (this=0x810ab48c8 , __sb=0x810ab36f8 >>>> <__gnu_internal::buf_cout_sync>) >>>> at >>>> /wrkdirs/usr/ports/lang/gcc8/work/.build/powerpc64-portbld-freebsd13.0/libstdc++-v3/include/bits/basic_ios.tcc:126 >>>> #5 0x00081093e644 in std::basic_ostream >>>> >::basic_ostream (__sb=, this=, >>>> __in_chrg=, __vtt_parm=) >>>> at >>>> /wrkdirs/usr/ports/lang/gcc8/work/.build/powerpc64-portbld-freebsd13.0/libstdc++-v3/include/bits/basic_ios.h:460 >>>> #6 std::ios_base::Init::Init (this=) at >>>> /wrkdirs/usr/ports/lang/gcc8/work/gcc-8.3.0/libstdc++-v3/src/c++98/ios_init.cc:91 >>>> #7 std::ios_base::Init::Init (this=) at >>>> /wrkdirs/usr/ports/lang/gcc8/work/gcc-8.3.0/libstdc++-v3/src/c++98/ios_init.cc:78 >>>> #8 0x1000334c in __static_initialization_and_destruction_0 >>>> (__initialize_p=__initialize_p@entry=1, __priority=, >>>> __priority@entry=65535) at compress.cpp:273 >>>> #9 0x10004c2c in _GLOBAL__sub_I_compress.cpp(void) () at >>>> compress.cpp:273 >>>> #10 0x00081005dfa0 in objlist_call_init (list=, >>>> lockstate=) at /usr/src/libexec/rtld-elf/rtld.c:2728 >>>> #11 0x00081005c830 in _rtld (sp=, exit_proc=>>> out>, objp=) at /usr/src/libexec/rtld-elf/rtld.c:765 >>>> #12 0x00081005a240 in ._rtld_start () at >>>> /usr/src/libexec/rtld-elf/po
Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"
On 2019-May-23, at 11:47, Jan Beich wrote: > Mark Millard writes: > >> Unfortunately poudiere bulk tar archives of failures do not >> catch the /tmp/* material from: >> >> cc: error: unable to execute command: Abort trap (core dumped) >> cc: error: clang frontend command failed due to signal (use -v to see >> invocation) >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM >> 8.0.0) >> Target: powerpc64-unknown-freebsd13.0 >> Thread model: posix >> InstalledDir: /usr/bin > > Do you have the build log? Maybe it's possible to reproduce simply by adding > -target powerpc64-unknown-freebsd13.0 while cross-building that particular > file > using otherwise the same command line options as native build. I have expanded the poudriere bulk's tar of the failure and rerun the command from there. The problem reproduced: # ls -lTdt /tmp/nir_constant_expressions-9b094e.* -rw-r--r-- 1 root wheel11069 May 23 12:08:35 2019 /tmp/nir_constant_expressions-9b094e.sh -rw-r--r-- 1 root wheel 1951892 May 23 12:08:35 2019 /tmp/nir_constant_expressions-9b094e.c So I gzip'd the .c and created: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082 with the two files as 2 attachments. === 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"
