Date: Tue, 16 Oct 2018 09:15:02 -0700 From: Mark Millard <marklmi@yahoo.com> To: David Chisnall <theraven@FreeBSD.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions? Message-ID: <113B9196-2951-477A-A508-FA0F8E5598AC@yahoo.com> In-Reply-To: <F39B293E-1E88-4378-A3E4-38F5FB470571@yahoo.com> References: <5449BAA6-E022-4DE4-870A-8AE132A6F9FA@yahoo.com> <61B6C299-2F93-4678-8928-3CABDFED6623@FreeBSD.org> <D57DACD6-1523-4D56-B8F1-F85B23693E77@yahoo.com> <F39B293E-1E88-4378-A3E4-38F5FB470571@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[WITH_LLVM_LIBUNWIND=3D 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: >=20 >> On 2018-Oct-13, at 10:15 AM, David Chisnall <theraven at FreeBSD.org> = wrote: >>=20 >>> 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. >>=20 >> I see. Good to know. >=20 > Hmm. As of head -r339076 the src.conf man page says: >=20 > WITHOUT_LLVM_LIBUNWIND > Set to use GCC's stack unwinder (instead of LLVM's = libunwind). >=20 > This is a default setting on arm/arm, arm/armv6, = arm/armv7, > powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and > sparc64/sparc64. >=20 > I believe arm/armv7, arm/armv6, and arm/arm are using clang for such > vintages: >=20 > WITH_CLANG_BOOTSTRAP > Set to build the Clang C/C++ compiler during the bootstrap = phase > of the build. >=20 > This is a default setting on amd64/amd64, arm/arm, = arm/armv6, > arm/armv7, arm64/aarch64 and i386/i386. >=20 >=20 > But may be the man page is just out of date for WITHOUT_LLVM_LIBUNWIND = ? >=20 >>> I don=E2=80=99t believe that we are using any of those files on = platforms where clang is the default system compiler. LLVM=E2=80=99s = libUnwind should be able to handle PowerPC on Linux, so it=E2=80=99s = worth checking if this is the case on FreeBSD. >>=20 >> 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=3D215039 . = There was also >> the llvm submittal 31590. >>=20 >> 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.) >>=20 >> 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. >>=20 >>>> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain = <freebsd-toolchain@freebsd.org> wrote: >>>>=20 >>>> 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 : >>>>=20 >>>> /* 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. */ >>>>=20 >>>> 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.) >>>>=20 >>>> For me this has no real implications: I do not distribute >>>> my experiments. But I was surprised by what I read. >>>>=20 >>>> Looking I find: >>>>=20 >>>> # 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, >>>=20 >=20 As for using WITH_LLVM_LIBUNWIND=3D 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=3D100 --param = ggc-min-heapsize=3D131072 . . . --- UnwindRegistersRestore.o --- Using built-in specs. COLLECT_GCC=3D/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=3Dpowerpc64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --enable-gnu-indirect-function = --without-headers --with-gmp=3D/usr/local --with-pkgversion=3D'FreeBSD = Ports Collection for powerpc64' --with-system-zlib = --with-gxx-include-dir=3D/usr/include/c++/v1/ --with-sysroot=3D/ = --with-as=3D/usr/bin/powerpc64-unknown-freebsd12.0-as = --with-ld=3D/usr/bin/powerpc64-unknown-freebsd12.0-ld = --enable-initfini-array --prefix=3D/usr/local --localstatedir=3D/var = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Dpowerpc64-unknown-freebsd12.0 Thread model: posix gcc version 6.4.0 (FreeBSD Ports Collection for powerpc64)=20 COLLECT_GCC_OPTIONS=3D'-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=3Dgnu99' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wno-uninitialized' '-Wno-pointer-sign' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dmisleading-indentation' = '-Wno-error=3Dnonnull-compare' '-Wno-error=3Dshift-negative-value' = '-Wno-error=3Dtautological-compare' '-Wno-error=3Dunused-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/../../../../powerp= c64-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.po= werpc64/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): //=3D=3D=3D-------------------- UnwindRegistersRestore.S = ------------------------=3D=3D=3D// // // 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. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #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=3D215039 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?113B9196-2951-477A-A508-FA0F8E5598AC>