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

2017-07-23 Thread Mark Millard
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)

2017-07-23 Thread Mark Millard

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 

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

2017-07-23 Thread Shawn Webb
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)

2017-07-23 Thread Shawn Webb
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)

2017-07-23 Thread Shawn Webb
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)

2017-07-23 Thread Mark Millard
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)

2017-07-22 Thread Dimitry Andric
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)

2017-07-22 Thread Shawn Webb
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)

2017-07-22 Thread Shawn Webb
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)

2017-07-22 Thread Shawn Webb
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