Re: HEADS-UP: Merged llvm/clang 5.0.0 into -CURRENT (as of r321369)

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