Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On 2017-Jul-23, at 7:44 PM, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 09:16:26PM -0400, Shawn Webb wrote: >> On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: >>> On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: Shawn Webb shawn.webb at hardenedbsd.org wrote on Sat Jul 22 15:33:14 UTC 2017 : > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > default linker, but it looks like we in HardenedBSD are getting an > undefined symbol during buildworld. In an amd64 -> TARGET_ARCH=powerpc64 cross build context for FreeBSD -r321371 I got a similar report for the: /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: lldb_private::AppleObjCRuntime::GetFoundationVersion() >>> referenced by >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp >>> >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a part of your report (logfile). The context used devel/powerpc64-binutils : # /usr/local/powerpc64-freebsd/bin/ld --version GNU ld (GNU Binutils) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. (lld is not yet working option for powerpc64 as far as I know.) For this part of your report I doubt that anything that you listed is required for the problem to happen. In my context the error text was: --- lldb.full --- /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): In function `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): undefined reference to `lldb_private::AppleObjCRuntime::GetFoundationVersion()' >>> >>> Hey Mark, >>> >>> I wasn't doing a cross-build, but rather a native build for amd64. I'm >>> getting errors again. In fact, I'm getting the same error you just >>> posted above. I have no clue why the error's happening. That you're >>> also getting the error shows that the issue isn't specific to >>> HardenedBSD at the very least. >> >> I've figured out how to fully reproduce. The following assumes world >> still is at clang/llvm 4.0. The following also assumes the source tree >> is at /usr/src and is latest FreeBSD HEAD. And MAKEOBJDIRPREFIX is unset >> or left as default. Native build on amd64. >> >> 1. Set ld.lld as the linker: >> a. rm /usr/bin/ld >> b. ln -s ld.lld /usr/bin/ld >> c. Verify: `ld -version` should show: >> LLD 4.0.0 (FreeBSD 297347) (compatible with GNU linkers) >> 2. Ensure the object tree is clean: >> a. rm -rf /usr/obj/usr/src >> 3. Build world: >> a. make -sj$(sysctl -n hw.ncpu) buildworld >> 4. Relax, grab a drink, eat some Skittles >> 5. Come back to buildworld failing to link lldb.full in >> usr.bin/clang/lldb > > Found the regression: It looks like lldb 5.0.0 doesn't support being > compiled with SafeStack. I'll report this upstream to llvm. [These notes only apply to the undefined symbol for lldb_private::AppleObjCRuntime::GetFoundationVersion() .] Such a regerssion may be true as far as it goes but likely can not be all there is too it since (using the powerpc64 example): I did nothing that I know of to involve anything called SafeStack in my FreeBSD context (not HardenedBSD). So far as I know the gcc based devel/powerpc64-binutils variant of ld does not support -fsanitize=safe-stack but all the binutils were from the devel/powerpc64-binutils port. This makes it unlikely that -fsanitize=safe-stack would be supplied to any compile or link command in my context. For my context sanitize=safe-stack is not found by: grep sanitize=safe-stack /usr/src/Makefile* /usr/src/share/mk/* Nor does it occur in the typescript for my failing build or any other build. It was not in the cc+ command that ran the linker instance that produced the message that I got. === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On 2017-Jul-23, at 6:16 PM, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: >> On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: >>> Shawn Webb shawn.webb at hardenedbsd.org wrote on >>> Sat Jul 22 15:33:14 UTC 2017 : >>> I haven't nailed down whether it's SafeStack, CFI, or using lld as the default linker, but it looks like we in HardenedBSD are getting an undefined symbol during buildworld. >>> >>> In an amd64 -> TARGET_ARCH=powerpc64 cross build context >>> for FreeBSD -r321371 I got a similar report for the: >>> >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: >>> lldb_private::AppleObjCRuntime::GetFoundationVersion() >> referenced by >> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp >> >> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, >> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in >> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a >>> >>> part of your report (logfile). The context used >>> devel/powerpc64-binutils : >>> >>> # /usr/local/powerpc64-freebsd/bin/ld --version >>> GNU ld (GNU Binutils) 2.28 >>> Copyright (C) 2017 Free Software Foundation, Inc. >>> This program is free software; you may redistribute it under the terms of >>> the GNU General Public License version 3 or (at your option) a later >>> version. >>> This program has absolutely no warranty. >>> >>> (lld is not yet working option for powerpc64 as >>> far as I know.) >>> >>> For this part of your report I doubt that anything >>> that you listed is required for the problem to happen. >>> >>> In my context the error text was: >>> >>> --- lldb.full --- >>> /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): >>> In function >>> `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): >>> undefined reference to >>> `lldb_private::AppleObjCRuntime::GetFoundationVersion()' >> >> Hey Mark, >> >> I wasn't doing a cross-build, but rather a native build for amd64. I'm >> getting errors again. In fact, I'm getting the same error you just >> posted above. I have no clue why the error's happening. That you're >> also getting the error shows that the issue isn't specific to >> HardenedBSD at the very least. > > I've figured out how to fully reproduce. The following assumes world > still is at clang/llvm 4.0. The following also assumes the source tree > is at /usr/src and is latest FreeBSD HEAD. And MAKEOBJDIRPREFIX is unset > or left as default. Native build on amd64. > > 1. Set ld.lld as the linker: > a. rm /usr/bin/ld > b. ln -s ld.lld /usr/bin/ld > c. Verify: `ld -version` should show: > LLD 4.0.0 (FreeBSD 297347) (compatible with GNU linkers) > 2. Ensure the object tree is clean: > a. rm -rf /usr/obj/usr/src > 3. Build world: > a. make -sj$(sysctl -n hw.ncpu) buildworld > 4. Relax, grab a drink, eat some Skittles > 5. Come back to buildworld failing to link lldb.full in > usr.bin/clang/lldb FYI: This may be sufficient but it is not necessary for the: error: undefined symbol: lldb_private::AppleObjCRuntime::GetFoundationVersion() type of message, at least for some TARGET_ARCH 's. (I've not seen the other undefined symbols yet in my activities so I make no claims for them.) My powerpc64 example was using ld V2.28 (and other binutils) from devel/powerpc64-binutils (/usr/local/powerpc64-freebsd/bin/ld and such), not lld. (lld does not work overall for powerpc64: it is not even an option for TARGET_ARCH=powerpc64 last I knew. Nor does the older type of system ld work overall for powerpc64.) So -B/usr/local/powerpc64-freebsd/bin/ was in use in the c++ command that ran the linker: c++ -target powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe -I/usr/src/contrib/llvm/tools/lldb/include -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 -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"\" -ffunction-sections -fdata-sections -g -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-
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sun, Jul 23, 2017 at 09:16:26PM -0400, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: > > On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > > > Shawn Webb shawn.webb at hardenedbsd.org wrote on > > > Sat Jul 22 15:33:14 UTC 2017 : > > > > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > > > default linker, but it looks like we in HardenedBSD are getting an > > > > undefined symbol during buildworld. > > > > > > In an amd64 -> TARGET_ARCH=powerpc64 cross build context > > > for FreeBSD -r321371 I got a similar report for the: > > > > > > /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: > > > lldb_private::AppleObjCRuntime::GetFoundationVersion() > > > >>> referenced by > > > >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp > > > >>> > > > >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > > >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in > > > >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a > > > > > > part of your report (logfile). The context used > > > devel/powerpc64-binutils : > > > > > > # /usr/local/powerpc64-freebsd/bin/ld --version > > > GNU ld (GNU Binutils) 2.28 > > > Copyright (C) 2017 Free Software Foundation, Inc. > > > This program is free software; you may redistribute it under the terms of > > > the GNU General Public License version 3 or (at your option) a later > > > version. > > > This program has absolutely no warranty. > > > > > > (lld is not yet working option for powerpc64 as > > > far as I know.) > > > > > > For this part of your report I doubt that anything > > > that you listed is required for the problem to happen. > > > > > > In my context the error text was: > > > > > > --- lldb.full --- > > > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): > > > In function > > > `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': > > > /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): > > > undefined reference to > > > `lldb_private::AppleObjCRuntime::GetFoundationVersion()' > > > > Hey Mark, > > > > I wasn't doing a cross-build, but rather a native build for amd64. I'm > > getting errors again. In fact, I'm getting the same error you just > > posted above. I have no clue why the error's happening. That you're > > also getting the error shows that the issue isn't specific to > > HardenedBSD at the very least. > > I've figured out how to fully reproduce. The following assumes world > still is at clang/llvm 4.0. The following also assumes the source tree > is at /usr/src and is latest FreeBSD HEAD. And MAKEOBJDIRPREFIX is unset > or left as default. Native build on amd64. > > 1. Set ld.lld as the linker: >a. rm /usr/bin/ld >b. ln -s ld.lld /usr/bin/ld >c. Verify: `ld -version` should show: > LLD 4.0.0 (FreeBSD 297347) (compatible with GNU linkers) > 2. Ensure the object tree is clean: >a. rm -rf /usr/obj/usr/src > 3. Build world: >a. make -sj$(sysctl -n hw.ncpu) buildworld > 4. Relax, grab a drink, eat some Skittles > 5. Come back to buildworld failing to link lldb.full in >usr.bin/clang/lldb Found the regression: It looks like lldb 5.0.0 doesn't support being compiled with SafeStack. I'll report this upstream to llvm. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sun, Jul 23, 2017 at 07:34:47PM -0400, Shawn Webb wrote: > On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > > Shawn Webb shawn.webb at hardenedbsd.org wrote on > > Sat Jul 22 15:33:14 UTC 2017 : > > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > > default linker, but it looks like we in HardenedBSD are getting an > > > undefined symbol during buildworld. > > > > In an amd64 -> TARGET_ARCH=powerpc64 cross build context > > for FreeBSD -r321371 I got a similar report for the: > > > > /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: > > lldb_private::AppleObjCRuntime::GetFoundationVersion() > > >>> referenced by > > >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp > > >>> > > >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in > > >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a > > > > part of your report (logfile). The context used > > devel/powerpc64-binutils : > > > > # /usr/local/powerpc64-freebsd/bin/ld --version > > GNU ld (GNU Binutils) 2.28 > > Copyright (C) 2017 Free Software Foundation, Inc. > > This program is free software; you may redistribute it under the terms of > > the GNU General Public License version 3 or (at your option) a later > > version. > > This program has absolutely no warranty. > > > > (lld is not yet working option for powerpc64 as > > far as I know.) > > > > For this part of your report I doubt that anything > > that you listed is required for the problem to happen. > > > > In my context the error text was: > > > > --- lldb.full --- > > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): > > In function > > `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': > > /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): > > undefined reference to > > `lldb_private::AppleObjCRuntime::GetFoundationVersion()' > > Hey Mark, > > I wasn't doing a cross-build, but rather a native build for amd64. I'm > getting errors again. In fact, I'm getting the same error you just > posted above. I have no clue why the error's happening. That you're > also getting the error shows that the issue isn't specific to > HardenedBSD at the very least. I've figured out how to fully reproduce. The following assumes world still is at clang/llvm 4.0. The following also assumes the source tree is at /usr/src and is latest FreeBSD HEAD. And MAKEOBJDIRPREFIX is unset or left as default. Native build on amd64. 1. Set ld.lld as the linker: a. rm /usr/bin/ld b. ln -s ld.lld /usr/bin/ld c. Verify: `ld -version` should show: LLD 4.0.0 (FreeBSD 297347) (compatible with GNU linkers) 2. Ensure the object tree is clean: a. rm -rf /usr/obj/usr/src 3. Build world: a. make -sj$(sysctl -n hw.ncpu) buildworld 4. Relax, grab a drink, eat some Skittles 5. Come back to buildworld failing to link lldb.full in usr.bin/clang/lldb Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sun, Jul 23, 2017 at 04:13:18PM -0700, Mark Millard wrote: > Shawn Webb shawn.webb at hardenedbsd.org wrote on > Sat Jul 22 15:33:14 UTC 2017 : > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > default linker, but it looks like we in HardenedBSD are getting an > > undefined symbol during buildworld. > > In an amd64 -> TARGET_ARCH=powerpc64 cross build context > for FreeBSD -r321371 I got a similar report for the: > > /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: > lldb_private::AppleObjCRuntime::GetFoundationVersion() > >>> referenced by > >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp > >>> > >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in > >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a > > part of your report (logfile). The context used > devel/powerpc64-binutils : > > # /usr/local/powerpc64-freebsd/bin/ld --version > GNU ld (GNU Binutils) 2.28 > Copyright (C) 2017 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later version. > This program has absolutely no warranty. > > (lld is not yet working option for powerpc64 as > far as I know.) > > For this part of your report I doubt that anything > that you listed is required for the problem to happen. > > In my context the error text was: > > --- lldb.full --- > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): > In function > `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, > lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': > /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): > undefined reference to > `lldb_private::AppleObjCRuntime::GetFoundationVersion()' Hey Mark, I wasn't doing a cross-build, but rather a native build for amd64. I'm getting errors again. In fact, I'm getting the same error you just posted above. I have no clue why the error's happening. That you're also getting the error shows that the issue isn't specific to HardenedBSD at the very least. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
Shawn Webb shawn.webb at hardenedbsd.org wrote on Sat Jul 22 15:33:14 UTC 2017 : > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > default linker, but it looks like we in HardenedBSD are getting an > undefined symbol during buildworld. In an amd64 -> TARGET_ARCH=powerpc64 cross build context for FreeBSD -r321371 I got a similar report for the: /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: lldb_private::AppleObjCRuntime::GetFoundationVersion() >>> referenced by >>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp >>> >>> Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, >>> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in >>> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a part of your report (logfile). The context used devel/powerpc64-binutils : # /usr/local/powerpc64-freebsd/bin/ld --version GNU ld (GNU Binutils) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. (lld is not yet working option for powerpc64 as far as I know.) For this part of your report I doubt that anything that you listed is required for the problem to happen. In my context the error text was: --- lldb.full --- /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): In function `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): undefined reference to `lldb_private::AppleObjCRuntime::GetFoundationVersion()' === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On 22 Jul 2017, at 19:38, Shawn Webb wrote: > > On Sat, Jul 22, 2017 at 01:32:17PM -0400, Shawn Webb wrote: >> On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: >>> On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: Hi, I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 (trunk r308421) into head. Universe builds went just fine, but if you encounter any snags during world and/or kernel builds, please file PRs. Since upstream has just created their 5.0.0 release branch, this is a good month to shake out any remaining issues for FreeBSD. If you are certain bugs or regressions you encounter are due to upstream, file PRs there, but otherwise, just report them on the FreeBSD bug tracker. >>> >>> Hey Dimitry, >>> >>> Thank you very much for your hard work and dedication to bringing the >>> llvm toolchain to FreeBSD. >>> >>> I haven't nailed down whether it's SafeStack, CFI, or using lld as the >>> default linker, but it looks like we in HardenedBSD are getting an >>> undefined symbol during buildworld. >>> >>> Here's the logfile: >>> >>> http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText >>> >>> I'm working right now on figuring out what caused it. I'll report back >>> when I know more. >> >> Found the culprit: WITH_LLD_BOOTSTRAP. It looks like when >> MK_LLD_BOOTSTRAP is set to yes, then you get the error in the Jenkins >> log above. At least, on amd64. I do _not_ get the error on arm64. > > I forgot to mention that WITH_LLD_IS_LD is set, too. I haven't tested > WITH_LLD_BOOTSTRAP && WITHOUT_LLD_IS_LD. Hi Shawn, I've tried reproducing, using WITH_LLD_BOOTSTRAP and WITH_LLD_IS_LD, but buildworld finishes without issues for me. This is with explicit __MAKE_CONF=/dev/null and SRCCONF=/dev/null environment variables, so everything else is at its defaults. Do you have any other particular settings, like modified default CFLAGS or LDFLAGS, either in your share/mk/*.mk files, or somewhere else? -Dimitry signature.asc Description: Message signed with OpenPGP
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sat, Jul 22, 2017 at 01:32:17PM -0400, Shawn Webb wrote: > On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: > > On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > > > Hi, > > > > > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > > > (trunk r308421) into head. Universe builds went just fine, but if you > > > encounter any snags during world and/or kernel builds, please file PRs. > > > > > > Since upstream has just created their 5.0.0 release branch, this is a > > > good month to shake out any remaining issues for FreeBSD. If you are > > > certain bugs or regressions you encounter are due to upstream, file PRs > > > there, but otherwise, just report them on the FreeBSD bug tracker. > > > > Hey Dimitry, > > > > Thank you very much for your hard work and dedication to bringing the > > llvm toolchain to FreeBSD. > > > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > > default linker, but it looks like we in HardenedBSD are getting an > > undefined symbol during buildworld. > > > > Here's the logfile: > > > > http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText > > > > I'm working right now on figuring out what caused it. I'll report back > > when I know more. > > Found the culprit: WITH_LLD_BOOTSTRAP. It looks like when > MK_LLD_BOOTSTRAP is set to yes, then you get the error in the Jenkins > log above. At least, on amd64. I do _not_ get the error on arm64. I forgot to mention that WITH_LLD_IS_LD is set, too. I haven't tested WITH_LLD_BOOTSTRAP && WITHOUT_LLD_IS_LD. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sat, Jul 22, 2017 at 11:33:08AM -0400, Shawn Webb wrote: > On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > > Hi, > > > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > > (trunk r308421) into head. Universe builds went just fine, but if you > > encounter any snags during world and/or kernel builds, please file PRs. > > > > Since upstream has just created their 5.0.0 release branch, this is a > > good month to shake out any remaining issues for FreeBSD. If you are > > certain bugs or regressions you encounter are due to upstream, file PRs > > there, but otherwise, just report them on the FreeBSD bug tracker. > > Hey Dimitry, > > Thank you very much for your hard work and dedication to bringing the > llvm toolchain to FreeBSD. > > I haven't nailed down whether it's SafeStack, CFI, or using lld as the > default linker, but it looks like we in HardenedBSD are getting an > undefined symbol during buildworld. > > Here's the logfile: > > http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText > > I'm working right now on figuring out what caused it. I'll report back > when I know more. Found the culprit: WITH_LLD_BOOTSTRAP. It looks like when MK_LLD_BOOTSTRAP is set to yes, then you get the error in the Jenkins log above. At least, on amd64. I do _not_ get the error on arm64. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
On Sat, Jul 22, 2017 at 02:36:03PM +0200, Dimitry Andric wrote: > Hi, > > I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 > (trunk r308421) into head. Universe builds went just fine, but if you > encounter any snags during world and/or kernel builds, please file PRs. > > Since upstream has just created their 5.0.0 release branch, this is a > good month to shake out any remaining issues for FreeBSD. If you are > certain bugs or regressions you encounter are due to upstream, file PRs > there, but otherwise, just report them on the FreeBSD bug tracker. Hey Dimitry, Thank you very much for your hard work and dedication to bringing the llvm toolchain to FreeBSD. I haven't nailed down whether it's SafeStack, CFI, or using lld as the default linker, but it looks like we in HardenedBSD are getting an undefined symbol during buildworld. Here's the logfile: http://jenkins.hardenedbsd.org:8180/jenkins/job/HardenedBSD-CURRENT-amd64/910/consoleText I'm working right now on figuring out what caused it. I'll report back when I know more. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)
Hi, I have merged clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 (trunk r308421) into head. Universe builds went just fine, but if you encounter any snags during world and/or kernel builds, please file PRs. Since upstream has just created their 5.0.0 release branch, this is a good month to shake out any remaining issues for FreeBSD. If you are certain bugs or regressions you encounter are due to upstream, file PRs there, but otherwise, just report them on the FreeBSD bug tracker. -Dimitry signature.asc Description: Message signed with OpenPGP
