[WITH_LLVM_LIBUNWIND= is still broken for powerpc64 (and likely powerpc).] On 2018-Oct-13, at 7:54 PM, Mark Millard <marklmi at yahoo.com> wrote:
> On 2018-Oct-13, at 7:40 PM, Mark Millard <marklmi at yahoo.com> wrote: > >> On 2018-Oct-13, at 10:15 AM, David Chisnall <theraven at FreeBSD.org> wrote: >> >>> This is a known problem with the GCC runtime libraries. GCC 4.3 and later >>> have a much better exemption (which talks about any eligible compilation >>> process, rather than being compiled with GCC), but those are GPLv3 and so >>> unacceptable for FreeBSD. >> >> I see. Good to know. > > Hmm. As of head -r339076 the src.conf man page says: > > WITHOUT_LLVM_LIBUNWIND > Set to use GCC's stack unwinder (instead of LLVM's libunwind). > > This is a default setting on arm/arm, arm/armv6, arm/armv7, > powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and > sparc64/sparc64. > > I believe arm/armv7, arm/armv6, and arm/arm are using clang for such > vintages: > > WITH_CLANG_BOOTSTRAP > Set to build the Clang C/C++ compiler during the bootstrap phase > of the build. > > This is a default setting on amd64/amd64, arm/arm, arm/armv6, > arm/armv7, arm64/aarch64 and i386/i386. > > > But may be the man page is just out of date for WITHOUT_LLVM_LIBUNWIND ? > >>> I don’t believe that we are using any of those files on platforms where >>> clang is the default system compiler. LLVM’s libUnwind should be able to >>> handle PowerPC on Linux, so it’s worth checking if this is the case on >>> FreeBSD. >> >> Last I tried llvm's libunwind for powerpc64 was back in 2016-Dec/2017-Jan. >> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039 . There was also >> the llvm submittal 31590. >> >> I might try it again at some point. But clang and llvm have other issues for >> use for buildworld buildkernel as well as I understand. (But I'm doing some >> new experiments these days.) >> >> I've no clue if llvm's libunwind is intended to be compliant with the >> powerpc64 and powerpc ABIs that FreeBSD bases itself on for the powerpc >> family. >> >>>> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain >>>> <freebsd-toolchain@freebsd.org> wrote: >>>> >>>> While investigating powerpc64 C++ exception handling for >>>> builds under devel/powerpc64-gcc I ran into the following >>>> in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : >>>> >>>> /* As a special exception, if you link this library with other files, >>>> some of which are compiled with GCC, to produce an executable, >>>> this library does not by itself cause the resulting executable >>>> to be covered by the GNU General Public License. >>>> This exception does not however invalidate any other reasons why >>>> the executable file might be covered by the GNU General Public License. */ >>>> >>>> So in contexts were clang/llvm is used to exclusion . . . are >>>> any such files in use? (I happen to be using devel/powerpc64-gcc at >>>> the moment.) >>>> >>>> For me this has no real implications: I do not distribute >>>> my experiments. But I was surprised by what I read. >>>> >>>> Looking I find: >>>> >>>> # grep -r "some of which are compiled with GCC" /usr/src/* | more >>>> /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are >>>> compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are compiled >>>> with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are compiled >>>> with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are >>>> compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are >>>> compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are >>>> compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are >>>> compiled with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/mips/mips16.S: some of which are compiled >>>> with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled with >>>> GCC, to produce an executable, >>>> /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled with >>>> GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled with >>>> GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled with >>>> GCC, to produce an executable, >>>> /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-single.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/tsystem.h: some of which are compiled with GCC, to >>>> produce an executable, >>>> /usr/src/contrib/gcc/typeclass.h: some of which are compiled with GCC, >>>> to produce an executable, >>>> /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are compiled >>>> with GCC, to produce an executable, >>>> /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are compiled >>>> with GCC, to produce an executable, >>> > As for using WITH_LLVM_LIBUNWIND= for powerpc64 with devel/powerpc64-gcc based on the current build infrastructure and the notation in some of the files (simply adding the line to my alternately-named equivalent of src.conf for such a build): . . . GNU C99 (FreeBSD Ports Collection for powerpc64) version 6.4.0 (powerpc64-unknown-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 . . . --- UnwindRegistersRestore.o --- Using built-in specs. COLLECT_GCC=/usr/local/bin/powerpc64-unknown-freebsd12.0-gcc Target: powerpc64-unknown-freebsd12.0 Configured with: /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/configure --target=powerpc64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++ --enable-gnu-indirect-function --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/bin/powerpc64-unknown-freebsd12.0-as --with-ld=/usr/bin/powerpc64-unknown-freebsd12.0-ld --enable-initfini-array --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ --build=powerpc64-unknown-freebsd12.0 Thread model: posix gcc version 6.4.0 (FreeBSD Ports Collection for powerpc64) COLLECT_GCC_OPTIONS='-gdwarf-2' '-B' '/usr/local/powerpc64-unknown-freebsd12.0/bin/' '-O2' '-pipe' '-I' '/usr/src/contrib/llvm/projects/libunwind/include' '-I' '/usr/src/lib/libgcc_eh' '-D' '_LIBUNWIND_IS_NATIVE_ONLY' '-g' '-std=gnu99' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' '-Wno-uninitialized' '-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=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' '-v' '-c' '-o' 'UnwindRegistersRestore.o' . . . --- UnwindRegistersRestore.o --- ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/../../../../powerpc64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/contrib/llvm/projects/libunwind/include /usr/src/lib/libgcc_eh /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include End of search list. . . . --- UnwindRegistersRestore.o --- /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S: Assembler messages: /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:98: Error: junk at end of line, first unrecognized character is `@' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:98: Error: junk at end of line, first unrecognized character is `@' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:100: Error: unrecognized opcode: `void' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:102: Error: unrecognized opcode: `on' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:103: Error: unrecognized opcode: `thread_state' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:106: Error: unrecognized opcode: `restore' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:107: Error: unrecognized opcode: `skip' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:108: Error: unrecognized opcode: `skip' /usr/src/contrib/llvm/projects/libunwind/src/UnwindRegistersRestore.S:110: Error: unrecognized opcode: `skip' . . . (I will not list the long list of errors.) It appears that the file expects C-preprocessor handling that is not applied (#lines not treated as comments, #if defined(...) ignored): //===-------------------- UnwindRegistersRestore.S ------------------------===// // // The LLVM Compiler Infrastructure // // This file is dual licensed under the MIT and the University of Illinois Open // Source Licenses. See LICENSE.TXT for details. // //===----------------------------------------------------------------------===// #include "assembly.h" .text #if defined(__i386__) DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_x866jumptoEv) # # void libunwind::Registers_x86::jumpto() # # On entry: # + + # +-----------------------+ # + thread_state pointer + # +-----------------------+ # + return address + # +-----------------------+ <-- SP # + + movl 4(%esp), %eax # set up eax and ret on new stack location movl 28(%eax), %edx # edx holds new stack pointer subl $8,%edx movl %edx, 28(%eax) movl 0(%eax), %ebx movl %ebx, 0(%edx) movl 40(%eax), %ebx movl %ebx, 4(%edx) # we now have ret and eax pushed onto where new stack will be # restore all registers movl 4(%eax), %ebx movl 8(%eax), %ecx movl 12(%eax), %edx movl 16(%eax), %edi movl 20(%eax), %esi movl 24(%eax), %ebp movl 28(%eax), %esp # skip ss # skip eflags pop %eax # eax was already pushed on new stack ret # eip was already pushed on new stack # skip cs # skip ds # skip es # skip fs # skip gs . . . There is also the oddity of the __ppc__ code's notation: #elif defined(__ppc__) DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_ppc6jumptoEv) ; ; void libunwind::Registers_ppc::jumpto() ; ; On entry: ; thread_state pointer is in r3 ; ; restore integral registerrs ; skip r0 for now ; skip r1 for now lwz r2, 16(r3) ; skip r3 for now ; skip r4 for now ; skip r5 for now lwz r6, 32(r3) lwz r7, 36(r3) lwz r8, 40(r3) lwz r9, 44(r3) lwz r10, 48(r3) lwz r11, 52(r3) lwz r12, 56(r3) lwz r13, 60(r3) . . . Justin Hibbits wrote about this notation ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039 comment 1 ): QUOTE The naked 'r*' and 'f*' register designations are a Darwinism. SysV notation requires '%r*' and '%f*', or naked numbers. This should probably be filed upstream as well. END QUOTE This suggests that, for __ppc__, LLVM's libunwind is Darwin specific still. === 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"
