On 2017-Jul-23, at 7:44 PM, Shawn Webb <shawn.webb at hardenedbsd.org> 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 _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"