date:20190519

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #17 from Mark Millard  ---
(In reply to Mark Millard from comment #16)

Using:

g++8 -c small_link_failure.cpp

instead of the system-clang-8 c++ also reproduces
getting the messages after the other steps.

Using the program:

/usr/local/bin/ld

(from devel/binutils) instead of:

/usr/bin/powerpc64-unknown-freebsd13.0-ld

(from base/binutils) also reproduces getting the
messages.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

2019-05-19 Thread Mark Millard via freebsd-toolchain

[I finally provide a small source file and steps for
processing it to produce the BFD_ASSERT notices.]

On 2019-May-19, at 11:06, Dimitry Andric  wrote:

> On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain 
>  wrote:
>> This was in a poudriere bulk build on a head -r347549 based powerpc64
>> system with system clang 8 for cc and c++ and base/binutils
>> for the likes of ld. (The system has the llvm libunwind patches
>> for powerpc64 so throwing c++ exceptions work.)
>> 
>> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG 
>> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
>> -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden 
>> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W 
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
>> -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
>> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
>> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include 
>> -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include  
>> -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
>> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
>> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
>> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/
 ../
>> lib:/usr/local/lib" lib/libLLVM-6.0.so && :
>> FAILED: lib/libLTO.so.6.0.1
>> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem 
>> /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem 
>> /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time 
>> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
>> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
>> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
>> -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG 
>> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
>> -DNDEBUG -isystem /usr/local/include  -fstack-protector-strong   
>> -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
>> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
>> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
>> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
>> -Wl,-rpath,"\$ORIGIN/../lib:/usr/
 loc
>> al/lib" lib/libLLVM-6.0.so && :
>> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
>> fail elflink.c:2935
>> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
>> fail elflink.c:2935
> 
> See .  I think this is a BFD ld bug,
> but I still haven't been able to come up with a small test case.  Any
> help appreciated. :-)

NOTE: Only tested in the powerpc64 context, with system clang 8
for c++ and base/binutil for ld and such.

I used the simple_version_script.map from llvm60 in my environment.

(Also noted in bugzilla comment #13:)

The following small source code file and the few steps
to build/link it produce the message:

# more small_link_failure.cpp
unsigned long fixed_seed_override= 0xdeadc0de;

inline unsigned long get_execution_seed()
{
  const  unsigned long seed_prime = 0xff51afd7ed558ccdULL;
  static unsigned long seed = fixed_seed_override ? fixed_seed_override
   : (unsigned long)seed_prime;
  return seed;
}

unsigned long f()
{
  return get_execution_seed();
}

# c++ -c small_link_failure.cpp

# rm -f small_link_failure.a
# /usr/bin/ar qc small_link_failure.a small_link_failure.o

# "/usr/bin/powerpc64-unknown-freebsd13.0-ld" \
"-Bshareable" \
"-o" "small_link_failure-1.0.so" \
"/usr/lib/crtbeginS.o" \
"--version-script" 
"/wrkdirs/usr/ports/devel/llvm60/work/.build/./lib/tools/llvm-shlib/simple_version_script.map"
 \
"--whole-archive" \
"small_link_failure.a" \
"--no-whole-archive" \
"-lm"

# /usr/bin/powerpc64-unknown-freebsd13.0-ld \
"-Bshareable" \
"-o" "small_link_failure.so.1.0.1" \
"small_link_failure-1.0.so"

The resultant output is:

/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
fail elflink.c:2935
/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
fail elflink.c:2935



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #16 from Mark Millard  ---
(In reply to Mark Millard from comment #15)

The following small source code file and the few steps
to build/link it produce the message:

# more small_link_failure.cpp
unsigned long fixed_seed_override= 0xdeadc0de;

inline unsigned long get_execution_seed()
{
  const  unsigned long seed_prime = 0xff51afd7ed558ccdULL;
  static unsigned long seed = fixed_seed_override ? fixed_seed_override
   : (unsigned long)seed_prime;
  return seed;
}

unsigned long f()
{
  return get_execution_seed();
}

# c++ -c small_link_failure.cpp

# rm -f small_link_failure.a
# /usr/bin/ar qc small_link_failure.a small_link_failure.o

# "/usr/bin/powerpc64-unknown-freebsd13.0-ld" \
"-Bshareable" \
"-o" "small_link_failure-1.0.so" \
"/usr/lib/crtbeginS.o" \
"--version-script"
"/wrkdirs/usr/ports/devel/llvm60/work/.build/./lib/tools/llvm-shlib/simple_version_script.map"
\
"--whole-archive" \
"small_link_failure.a" \
"--no-whole-archive" \
"-lm"

# /usr/bin/powerpc64-unknown-freebsd13.0-ld \
"-Bshareable" \
"-o" "small_link_failure.so.1.0.1" \
"small_link_failure-1.0.so"

The result is:

/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion
fail elflink.c:2935
/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion
fail elflink.c:2935

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #15 from Mark Millard  ---
(In reply to Mark Millard from comment #14)

lib/IR/CMakeFiles/LLVMCore.dir/Core.cpp.o is not needed to
show the problem. So just:

rm lib/libLLVMCore.a

/usr/bin/ar qc lib/libLLVMCore.a \
lib/IR/CMakeFiles/LLVMCore.dir/Constants.cpp.o

"/usr/bin/powerpc64-unknown-freebsd13.0-ld" \
"-Bshareable" \
"-o" "lib/libLLVM-6.0.so" \
"/usr/lib/crtbeginS.o" \
"--version-script"
"/wrkdirs/usr/ports/devel/llvm60/work/.build/./lib/tools/llvm-shlib/simple_version_script.map"
\
"--whole-archive" \
"lib/libLLVMCore.a" \
"--no-whole-archive" \
"-lm"

/usr/bin/powerpc64-unknown-freebsd13.0-ld \
"-Bshareable" \
"-o" "lib/libLTO.so.6.0.1" \
"lib/libLLVM-6.0.so"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #14 from Mark Millard  ---
(In reply to Mark Millard from comment #13)

Exploring shrinking lib/libLLVMCore.a did not take
as long. Only Constants.cpp.o and Core.cpp.o are
required. The following sequence produces the messages:
(the tail is as in comment #13 but is repeated here)

rm lib/libLLVMCore.a

/usr/bin/ar qc lib/libLLVMCore.a \
lib/IR/CMakeFiles/LLVMCore.dir/Constants.cpp.o \
lib/IR/CMakeFiles/LLVMCore.dir/Core.cpp.o

/usr/bin/ranlib lib/libLLVMCore.a

"/usr/bin/powerpc64-unknown-freebsd13.0-ld" \
"-Bshareable" \
"-o" "lib/libLLVM-6.0.so" \
"/usr/lib/crtbeginS.o" \
"--version-script"
"/wrkdirs/usr/ports/devel/llvm60/work/.build/./lib/tools/llvm-shlib/simple_version_script.map"
\
"--whole-archive" \
"lib/libLLVMCore.a" \
"--no-whole-archive" \
"-lm"

/usr/bin/powerpc64-unknown-freebsd13.0-ld \
"-Bshareable" \
"-o" "lib/libLTO.so.6.0.1" \
"lib/libLLVM-6.0.so"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

2019-05-19 Thread Mark Millard via freebsd-toolchain




On 2019-May-19, at 11:06, Dimitry Andric  wrote:

> On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain 
>  wrote:
>> This was in a poudriere bulk build on a head -r347549 based powerpc64
>> system with system clang 8 for cc and c++ and base/binutils
>> for the likes of ld. (The system has the llvm libunwind patches
>> for powerpc64 so throwing c++ exceptions work.)
>> 
>> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG 
>> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
>> -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden 
>> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W 
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
>> -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
>> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
>> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include 
>> -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include  
>> -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
>> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
>> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
>> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/
 ../
>> lib:/usr/local/lib" lib/libLLVM-6.0.so && :
>> FAILED: lib/libLTO.so.6.0.1
>> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem 
>> /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem 
>> /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time 
>> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
>> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
>> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
>> -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG 
>> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
>> -DNDEBUG -isystem /usr/local/include  -fstack-protector-strong   
>> -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
>> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
>> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
>> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
>> -Wl,-rpath,"\$ORIGIN/../lib:/usr/
 loc
>> al/lib" lib/libLLVM-6.0.so && :
>> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
>> fail elflink.c:2935
>> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
>> fail elflink.c:2935
> 
> See .  I think this is a BFD ld bug,
> but I still haven't been able to come up with a small test case.  Any
> help appreciated. :-)

(Also noted in bugzilla comment #13:)

The following 2 link commands, producing and
using an vastly-smaller lib/libLLVM-6.0.so
reproduce the messages:

"/usr/bin/powerpc64-unknown-freebsd13.0-ld" \
"-Bshareable" \
"-o" "lib/libLLVM-6.0.so" \
"/usr/lib/crtbeginS.o" \
"--version-script" 
"/wrkdirs/usr/ports/devel/llvm60/work/.build/./lib/tools/llvm-shlib/simple_version_script.map"
 \
"--whole-archive" \
"lib/libLLVMCore.a" \
"--no-whole-archive" \
"-lm"

/usr/bin/powerpc64-unknown-freebsd13.0-ld \
"-Bshareable" \
"-o" "lib/libLTO.so.6.0.1" \
"lib/libLLVM-6.0.so"

It looks like lib/libLLVMCore.a would be next for
making it smaller.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #13 from Mark Millard  ---
(In reply to Mark Millard from comment #12)

The following 2 link commands, producing and
using an vastly-smaller lib/libLLVM-6.0.so
reproduce the messages:

"/usr/bin/powerpc64-unknown-freebsd13.0-ld" \
"-Bshareable" \
"-o" "lib/libLLVM-6.0.so" \
"/usr/lib/crtbeginS.o" \
"--version-script"
"/wrkdirs/usr/ports/devel/llvm60/work/.build/./lib/tools/llvm-shlib/simple_version_script.map"
\
"--whole-archive" \
"lib/libLLVMCore.a" \
"--no-whole-archive" \
"-lm"

/usr/bin/powerpc64-unknown-freebsd13.0-ld \
"-Bshareable" \
"-o" "lib/libLTO.so.6.0.1" \
"lib/libLLVM-6.0.so"

It looks like lib/libLLVMCore.a would be next for
making it smaller.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #12 from Mark Millard  ---
(In reply to Mark Millard from comment #11)

I've reduced the link command to:

# /usr/bin/powerpc64-unknown-freebsd13.0-ld "-Bshareable" "-o"
"lib/libLTO.so.6.0.1" "lib/libLLVM-6.0.so"
/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion
fail elflink.c:2935
/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion
fail elflink.c:2935

The only reason for -Bsharable is that there are more messages without it,
relating to _start, __progname, and environ.

So it seems lib/libLLVM-6.0.so is sufficient context for the
BFD_ASSERT to fail.


# readelf -sW lib/libLLVM-6.0.so | grep 'get_execution_seed.*seed' | more
 12020: 03c20f00 8 OBJECT  WEAK   DEFAULT   26
_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0 (2)
 21501: 03c20f08 8 OBJECT  WEAK   DEFAULT   26
_ZGVZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0 (2)
 68864: 03c20f00 8 OBJECT  WEAK   DEFAULT   26
_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed
 78345: 03c20f08 8 OBJECT  WEAK   DEFAULT   26
_ZGVZN4llvm7hashing6detail18get_execution_seedEvE4seed

# readelf -sW lib/libLLVM-6.0.so | grep 'bss' | more
  6278: 03c20f00 0 NOTYPE  GLOBAL DEFAULT   26
__bss_start@@LLVM_6.0 (2)
 63122: 03c20f00 0 NOTYPE  GLOBAL DEFAULT   26 __bss_start

Also:

  [26] .bss  NOBITS   03c20f00  03c10f00
   00056010    WA   0 0 8

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #11 from Mark Millard  ---
(In reply to Mark Millard from comment #10)

So far going down my own path seems to have confirmed
Dimitry Andric's comment #5 still applies, even for
powerpc64, but with the additional detail:

QUOTE
For _bfd_elf_fix_symbol_flags the later gdb output shows that *h has:

_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0
root.type = bfd_link_hash_defweak
is_weakalias = 1

*h->u.alias has:
__bss_start@@LLVM_6.0
root.type = bfd_link_hash_indirect
is_weakalias = 0

So that was def (via weakdef) and def->root.type==bfd_link_hash_indirect .
END QUOTE.

So the @@LLVM_6.0 name is involved and so is an alias to:
__bss_start@@LLVM_6.0 for bfd_link_hash_indirect.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

2019-05-19 Thread Mark Millard via freebsd-toolchain




On 2019-May-19, at 11:06, Dimitry Andric  wrote:

> On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain 
>  wrote:
>> This was in a poudriere bulk build on a head -r347549 based powerpc64
>> system with system clang 8 for cc and c++ and base/binutils
>> for the likes of ld. (The system has the llvm libunwind patches
>> for powerpc64 so throwing c++ exceptions work.)
>> 
>> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG 
>> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
>> -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden 
>> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W 
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
>> -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
>> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
>> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include 
>> -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include  
>> -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
>> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
>> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
>> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/
 ../
>> lib:/usr/local/lib" lib/libLLVM-6.0.so && :
>> FAILED: lib/libLTO.so.6.0.1
>> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem 
>> /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem 
>> /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time 
>> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
>> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
>> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
>> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
>> -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG 
>> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
>> -DNDEBUG -isystem /usr/local/include  -fstack-protector-strong   
>> -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
>> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
>> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
>> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
>> -Wl,-rpath,"\$ORIGIN/../lib:/usr/
 loc
>> al/lib" lib/libLLVM-6.0.so && :
>> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
>> fail elflink.c:2935
>> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
>> fail elflink.c:2935
> 
> See .  I think this is a BFD ld bug,
> but I still haven't been able to come up with a small test case.  Any
> help appreciated. :-)

I've put the evidence leading to the following in the
bugzilla report. The problem is tied to "seed" in:

/wrkdirs/usr/ports/devel/llvm60/work/llvm-6.0.1.src/include/llvm/ADT/Hashing.h 
's:

. . .
namespace llvm {
. . .

// All of the implementation details of actually computing the various hash
// code values are held within this namespace. These routines are included in
// the header file mainly to allow inlining and constant propagation.
namespace hashing {
namespace detail {
. . .

/// \brief A global, fixed seed-override variable.
///
/// This variable can be set using the \see llvm::set_fixed_execution_seed
/// function. See that function for details. Do not, under any circumstances,
/// set or read this variable.
extern size_t fixed_seed_override;

inline size_t get_execution_seed() {
  // FIXME: This needs to be a per-execution seed. This is just a placeholder
  // implementation. Switching to a per-execution seed is likely to flush out
  // instability bugs and so will happen as its own commit.
  //
  // However, if there is a fixed seed override set the first time this is
  // called, return that instead of the per-execution seed.
  const uint64_t seed_prime = 0xff51afd7ed558ccdULL;
  static size_t seed = fixed_seed_override ? fixed_seed_override
   : (size_t)seed_prime;
  return seed;
}

It ends up with *h in the reported BFD_ASSERT failures having:

_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0
root.type = bfd_link_hash_defweak
is_weakalias = 1

And *h->u.alias having:

__bss_start@@LLVM_6.0
root.type = bfd_link_hash_indirect
is_weakalias = 0

That means in the BFD_ASSERT:

def->root.type==bfd_link_hash_indirect

which fails the assert's: def->root.type == bfd_link_hash_defined


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-toolchain@freebsd.org mailing list

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #10 from Mark Millard  ---
(In reply to Mark Millard from comment #9)

The only source code that I find with:

_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed

(So: namespace llvm::hashing::detail:: ) is:

/wrkdirs/usr/ports/devel/llvm60/work/llvm-6.0.1.src/include/llvm/ADT/Hashing.h
's:

. . .
namespace llvm {
. . .

// All of the implementation details of actually computing the various hash
// code values are held within this namespace. These routines are included in
// the header file mainly to allow inlining and constant propagation.
namespace hashing {
namespace detail {
. . .

/// \brief A global, fixed seed-override variable.
///
/// This variable can be set using the \see llvm::set_fixed_execution_seed
/// function. See that function for details. Do not, under any circumstances,
/// set or read this variable.
extern size_t fixed_seed_override;

inline size_t get_execution_seed() {
  // FIXME: This needs to be a per-execution seed. This is just a placeholder
  // implementation. Switching to a per-execution seed is likely to flush out
  // instability bugs and so will happen as its own commit.
  //
  // However, if there is a fixed seed override set the first time this is
  // called, return that instead of the per-execution seed.
  const uint64_t seed_prime = 0xff51afd7ed558ccdULL;
  static size_t seed = fixed_seed_override ? fixed_seed_override
   : (size_t)seed_prime;
  return seed;
}

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Problem reports for toolch...@freebsd.org that need special attention

2019-05-19 Thread bugzilla-noreply

To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status  |Bug Id | Description
+---+---
Open|234232 | clang Assertion failed when building the port dev 

1 problems total for which you should take action.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237975] Add /usr/lib/libgomp.so symlink on Clang architectures

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237975

Dimitry Andric  changed:

   What|Removed |Added

  Flags||mfc-stable11+,
   ||mfc-stable12+

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237975] Add /usr/lib/libgomp.so symlink on Clang architectures

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237975

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |In Progress
 CC||d...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237975] Add /usr/lib/libgomp.so symlink on Clang architectures

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237975

--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:

Author: dim
Date: Sun May 19 20:13:55 UTC 2019
New revision: 347979
URL: https://svnweb.freebsd.org/changeset/base/347979

Log:
  To avoid unnecessarily modifying ports, add a -lgomp symlink, since GCC
  does not ship a -lomp symlink.  Also update OptionalObsoleteFiles for
  this, and add 32-bit variants while here.

  Submitted by: jbeich
  PR:   237975
  MFC after:3 days

Changes:
  head/lib/libomp/Makefile
  head/tools/build/mk/OptionalObsoleteFiles.inc

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

--- Comment #9 from Mark Millard  ---
(In reply to Mark Millard from comment #8)

Notes for the 2nd message and what follows. What follows
after the messaging appears interesting, noting the
comment's content.

(gdb) bt
#0  error_handler_internal (fmt=0x101dbc48 "BFD %s assertion fail %s:%d",
ap=0x3fffcdf8 "") at bfd.c:1093
#1  0x100204e8 in ld_bfd_error_handler (fmt=,
ap=) at ./ldmain.c:187
#2  0x10049b7c in _bfd_error_handler (fmt=) at
bfd.c:1178
#3  0x1002047c in ld_bfd_assert_handler (fmt=,
bfdver=, file=, line=) at
./ldmain.c:177
#4  0x10049de4 in bfd_assert (file=, line=) at bfd.c:1429
#5  0x100a520c in _bfd_elf_fix_symbol_flags (h=h@entry=0x811e77b70,
eif=eif@entry=0x3fffd0e0) at elflink.c:2935
#6  0x100a5800 in _bfd_elf_adjust_dynamic_symbol (h=0x811e77b70,
data=0x3fffd0e0) at elflink.c:2962
#7  0x10053d28 in bfd_link_hash_traverse (htab=0x810e5,
func=@0x10223738: 0x100a57b0 <_bfd_elf_adjust_dynamic_symbol>, info=) at linker.c:669
#8  0x100ac588 in bfd_elf_size_dynamic_sections
(output_bfd=0x810e4b000, soname=, rpath=0x8105fee80
"$ORIGIN/../lib:/usr/local/lib", filter_shlib=0x0, audit=0x0, depaudit=0x0, 
auxiliary_filters=, info=0x102324d8 ,
sinterpptr=) at elflink.c:6847
#9  0x10032b34 in gldelf64ppc_fbsd_before_allocation () at
eelf64ppc_fbsd.c:2107
#10 ppc_before_allocation () at eelf64ppc_fbsd.c:404
#11 0x100264e0 in ldemul_before_allocation () at ldemul.c:82
#12 0x1001d644 in lang_process () at ldlang.c:7593
#13 0x100047b8 in main (argc=, argv=) at
./ldmain.c:440

At #5 *h shows:

_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0
root.type = bfd_link_hash_defweak
is_weakalias = 1

*h->u.alias shows:

__bss_start@@LLVM_6.0
root.type = bfd_link_hash_indirect
is_weakalias = 0

So again: def->root.type== bfd_link_hash_indirect


The code continues after the two BFD_ASSERT messages.

If eventually reaches the xexit in main's :

477   /* Even if we're producing relocatable output, some non-fatal errors
should
478  be reported in the exit status.  (What non-fatal errors, if any,
do we
479  want to ignore for relocatable output?)  */
480   if (!config.make_executable && !force_make_executable)
481 {
482   if (verbose)
483 einfo (_("%P: link errors found, deleting executable `%s'\n"),
484output_filename);
485 
486   /* The file will be removed by ld_cleanup.  */
487   xexit (1);
488 }

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

2019-05-19 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

Mark Millard  changed:

   What|Removed |Added

 CC||marklmi26-f...@yahoo.com

--- Comment #8 from Mark Millard  ---
I see this sort of thing on powerpc64 with 2.32 as well.

The code reporting the problem is the last BFD_ASSERT
in:

static bfd_boolean
_bfd_elf_fix_symbol_flags (struct elf_link_hash_entry *h,
  struct elf_info_failed *eif)
{
. . .
 if (h->is_weakalias)
   {
 struct elf_link_hash_entry *def = weakdef (h);

 /* If the real definition is defined by a regular object file,
don't do anything special.  See the longer description in
_bfd_elf_adjust_dynamic_symbol, below.  */
 if (def->def_regular)
   {
 h = def;
 while ((h = h->u.alias) != def)
   h->is_weakalias = 0;
   }
 else
   {
 while (h->root.type == bfd_link_hash_indirect)
   h = (struct elf_link_hash_entry *) h->root.u.i.link;
 BFD_ASSERT (h->root.type == bfd_link_hash_defined
 || h->root.type == bfd_link_hash_defweak);
 BFD_ASSERT (def->def_dynamic);
 BFD_ASSERT (def->root.type == bfd_link_hash_defined);
 (*bed->elf_backend_copy_indirect_symbol) (eif->info, def, h);
   }
   }

 return TRUE;
}

For:

/usr/bin/powerpc64-unknown-freebsd13.0-ld "--eh-frame-hdr" "-Bshareable"
"--enable-new-dtags" "-o" "lib/libLTO.so.6.0.1" "/usr/lib/crti.o"
"/usr/lib/crtbeginS.o" "-L/usr/local/lib" "-L/usr/lib" "-z" "origin" "-O3"
"--gc-sections" "--version-script"
"/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports" "-soname"
"libLTO.so.6" "tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o"
"tools/lto/CMakeFiles/LTO.dir/lto.cpp.o" "-rpath"
"\$ORIGIN/../lib:/usr/local/lib" "lib/libLLVM-6.0.so" "-lc++" "-lm" "-lgcc"
"--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s"
"--no-as-needed" "/usr/lib/crtendS.o" "/usr/lib/crtn.o"

the backtrace at the first message report is:

Breakpoint 1, error_handler_internal (fmt=0x101dbc48 "BFD %s assertion fail
%s:%d", ap=0x3fffcdc8 "") at bfd.c:1093
1093{
(gdb) bt
#0  error_handler_internal (fmt=0x101dbc48 "BFD %s assertion fail %s:%d",
ap=0x3fffcdc8 "") at bfd.c:1093
#1  0x100204e8 in ld_bfd_error_handler (fmt=,
ap=) at ./ldmain.c:187
#2  0x10049b7c in _bfd_error_handler (fmt=) at
bfd.c:1178
#3  0x1002047c in ld_bfd_assert_handler (fmt=,
bfdver=, file=, line=) at
./ldmain.c:177
#4  0x10049de4 in bfd_assert (file=, line=) at bfd.c:1429
#5  0x100a520c in _bfd_elf_fix_symbol_flags (h=h@entry=0x811e77b70,
eif=eif@entry=0x3fffcf70) at elflink.c:2935
#6  0x100a54a0 in _bfd_elf_link_assign_sym_version (h=0x811e77b70,
data=0x3fffd148) at elflink.c:2363
#7  0x10053d28 in bfd_link_hash_traverse (htab=0x810e5,
func=@0x10223720: 0x100a5460 <_bfd_elf_link_assign_sym_version>,
info=) at linker.c:669
#8  0x100ab92c in bfd_elf_size_dynamic_sections
(output_bfd=0x810e4b000, soname=0x3fffdc87 "libLTO.so.6",
rpath=0x8105fee80 "$ORIGIN/../lib:/usr/local/lib", filter_shlib=0x0, 
audit=0x0, depaudit=0x0, auxiliary_filters=0x0, info=0x102324d8
, sinterpptr=0x3fffd280) at elflink.c:6316
#9  0x10032b34 in gldelf64ppc_fbsd_before_allocation () at
eelf64ppc_fbsd.c:2107
#10 ppc_before_allocation () at eelf64ppc_fbsd.c:404
#11 0x100264e0 in ldemul_before_allocation () at ldemul.c:82
#12 0x1001d644 in lang_process () at ldlang.c:7593
#13 0x100047b8 in main (argc=, argv=) at
./ldmain.c:440


For _bfd_elf_fix_symbol_flags the later gdb output shows that *h has:

_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0
root.type = bfd_link_hash_defweak
is_weakalias = 1

*h->u.alias has:
__bss_start@@LLVM_6.0
root.type = bfd_link_hash_indirect
is_weakalias = 0

So that was def (via weakdef) and def->root.type==bfd_link_hash_indirect .

(Not that I know what to do next with such information.)

The supporting details:

static inline struct elf_link_hash_entry *
weakdef (struct elf_link_hash_entry *h)
{
  while (h->is_weakalias)
h = h->u.alias;
  return h;
}

(gdb) down
#5  0x100a520c in _bfd_elf_fix_symbol_flags (h=h@entry=0x811e77b70,
eif=eif@entry=0x3fffcf70) at elflink.c:2935
2935  BFD_ASSERT (def->root.type == bfd_link_hash_defined);

(gdb) print def
$1 = 

(gdb) print *h
$5 = {root = {root = {next = 0x0, string = 0x811e77b30
"_ZZN4llvm7hashing6detail18get_execution_seedEvE4seed@@LLVM_6.0", hash =
1230121370}, type = bfd_link_hash_defweak, non_ir_ref_regular = 0, 
non_ir_ref_dynamic = 0, linker_def = 0, ldscript_def = 0, rel_from_abs = 0,
u = {undef = {next = 0x0, abfd = 0x811072340}, def = {next = 0x0, section =
0x811072340, value = 0}, i = {next =

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

2019-05-19 Thread Dimitry Andric

On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain 
 wrote:
> This was in a poudriere bulk build on a head -r347549 based powerpc64
> system with system clang 8 for cc and c++ and base/binutils
> for the likes of ld. (The system has the llvm libunwind patches
> for powerpc64 so throwing c++ exceptions work.)
> 
> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG 
> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
> -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden 
> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include 
> -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include  
> -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
> -Wl,-rpath,"\$ORIGIN/../
> lib:/usr/local/lib" lib/libLLVM-6.0.so && :
> FAILED: lib/libLTO.so.6.0.1
> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem 
> /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include 
> -fPIC -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
> -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG 
> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
> -DNDEBUG -isystem /usr/local/include  -fstack-protector-strong   
> -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
> -Wl,-rpath,"\$ORIGIN/../lib:/usr/loc
> al/lib" lib/libLLVM-6.0.so && :
> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
> fail elflink.c:2935
> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
> fail elflink.c:2935

See .  I think this is a BFD ld bug,
but I still haven't been able to come up with a small test case.  Any
help appreciated. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

2019-05-19 Thread Mark Millard via freebsd-toolchain

This was in a poudriere bulk build on a head -r347549 based powerpc64
system with system clang 8 for cc and c++ and base/binutils
for the likes of ld. (The system has the llvm libunwind patches
for powerpc64 so throwing c++ exceptions work.)

[4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong 
-isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem 
/usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
-ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong 
-isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem 
/usr/local/include  -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 
-Wl,--gc-sections  
-Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
 -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../
 lib:/usr/local/lib" lib/libLLVM-6.0.so && :
FAILED: lib/libLTO.so.6.0.1 
: && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem 
/usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include 
-fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
-ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong 
-isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem 
/usr/local/include  -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 
-Wl,--gc-sections  
-Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
 -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
-Wl,-rpath,"\$ORIGIN/../lib:/usr/loc
 al/lib" lib/libLLVM-6.0.so && :
/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
fail elflink.c:2935
/usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
fail elflink.c:2935

The assert is the last BFD_ASSERT shown below:

/* Fix up the flags for a symbol.  This handles various cases which
   can only be fixed after all the input files are seen.  This is
   currently called by both adjust_dynamic_symbol and
   assign_sym_version, which is unnecessary but perhaps more robust in
   the face of future changes.  */

static bfd_boolean
_bfd_elf_fix_symbol_flags (struct elf_link_hash_entry *h,
   struct elf_info_failed *eif)
{
. . .
  if (h->is_weakalias)
{
  struct elf_link_hash_entry *def = weakdef (h);

  /* If the real definition is defined by a regular object file,
 don't do anything special.  See the longer description in
 _bfd_elf_adjust_dynamic_symbol, below.  */
  if (def->def_regular)
{
  h = def;
  while ((h = h->u.alias) != def)
h->is_weakalias = 0;
}
  else
{
  while (h->root.type == bfd_link_hash_indirect)
h = (struct elf_link_hash_entry *) h->root.u.i.link;
  BFD_ASSERT (h->root.type == bfd_link_hash_defined
  || h->root.type == bfd_link_hash_defweak);
  BFD_ASSERT (def->def_dynamic);
  BFD_ASSERT (def->root.type == bfd_link_hash_defined);
  (*bed->elf_backend_copy_indirect_symbol) (eif->info, def, h);
}
}

  return TRUE;
}


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: FYI: Unable to build -r501994 ports' lang/gcc8 on clang 8 based powerpc64 system (no -O1 use): "does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls

2019-05-19 Thread Mark Millard via freebsd-toolchain

[It built with GNU ld (GNU Binutils) 2.32 as ld.]

On 2019-May-18, at 21:42, Mark Millard  wrote:

> On 2019-May-18, at 21:11, Mark Millard  wrote:
> 
>> This was in a poudriere bulk build on a head -r347549 based powerpc64
>> system with system clang 8 for cc and c++ and base/binutils
>> for ld. I was attempting a build with the -O1 changes disabled. (Note:
>> the system is self hosting for buildworld buildkernel via the clang 8
>> and base/binutils combination.)
>> 
>> So having issues with building lang/gcc8 is not limited  to gcc 4.2.1's
>> tool chain for powerpc64. (I've not yet tested -O1 use as the bulk build
>> still has lots of other things to build.)
>> 
>> . . .
>> c++: warning: argument unused during compilation: '-nopie' 
>> [-Wunused-command-line-argument]
>> /usr/bin/ld: libbackend.a(ipa-inline.o)(.text+0x540): sibling call 
>> optimization to 
>> `_ZN16function_summaryIP14ipa_fn_summaryE3getEP11cgraph_node' does not allow 
>> automatic multiple TOCs; recompile with 
>> -mminimal-toc or -fno-optimize-sibling-calls, or make 
>> `_ZN16function_summaryIP14ipa_fn_summaryE3getEP11cgraph_node' extern
>> /usr/bin/ld: libbackend.a(ipa-inline.o)(.text+0xa58): sibling call 
>> optimization to 
>> `_ZN16function_summaryIP14ipa_fn_summaryE3getEP11cgraph_node' does not allow 
>> automatic multiple TOCs; recompile with 
>> -mminimal-toc or -fno-optimize-sibling-calls, or make 
>> `_ZN16function_summaryIP14ipa_fn_summaryE3getEP11cgraph_node' extern
>> . . .
>> /usr/bin/ld: libbackend.a(ipa-inline.o)(.text+0x1150): sibling call 
>> optimization to 
>> `_ZN10hash_tableIN8hash_mapI8int_hashIiLi0ELin1EEP16ipa_call_summary21simple_hashmap_traitsI19default_hash_traitsIS2
>> _ES4_EE10hash_entryE11xcallocatorE19find_slot_with_hashERKij13insert_option' 
>> does not allow automatic multiple TOCs; recompile with -mminimal-toc or 
>> -fno-optimize-sibling-calls, or make `_ZN10hash_tab
>> leIN8hash_mapI8int_hashIiLi0ELin1EEP16ipa_call_summary21simple_hashmap_traitsI19default_hash_traitsIS2_ES4_EE10hash_entryE11xcallocatorE19find_slot_with_hashERKij13insert_option'
>>  extern
>> /usr/bin/ld: libbackend.a(ipa-inline.o)(.text+0x1224): sibling call 
>> optimization to 
>> `_ZN10hash_tableIN8hash_mapI8int_hashIiLi0ELin1EEP16ipa_call_summary21simple_hashmap_traitsI19default_hash_traitsIS2
>> _ES4_EE10hash_entryE11xcallocatorE19find_slot_with_hashERKij13insert_option' 
>> does not allow automatic multiple TOCs; recompile with -mminimal-toc or 
>> -fno-optimize-sibling-calls, or make `_ZN10hash_tab
>> leIN8hash_mapI8int_hashIiLi0ELin1EEP16ipa_call_summary21simple_hashmap_traitsI19default_hash_traitsIS2_ES4_EE10hash_entryE11xcallocatorE19find_slot_with_hashERKij13insert_option'
>>  extern
>> . . .
>> 
>> 
>> For reference . . .
>> 
>> # cc -v
>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 
>> 8.0.0)
>> Target: powerpc64-unknown-freebsd13.0
>> Thread model: posix
>> InstalledDir: /usr/bin
>> 
>> # c++ -v
>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 
>> 8.0.0)
>> Target: powerpc64-unknown-freebsd13.0
>> Thread model: posix
>> InstalledDir: /usr/bin
>> 
>> # ld -v
>> GNU ld (GNU Binutils) 2.32
>> 
>> 
>> I used:
>> 
>> # svnlite diff /usr/ports/lang/gcc8/ | more
>> Index: /usr/ports/lang/gcc8/Makefile
>> ===
>> --- /usr/ports/lang/gcc8/Makefile   (revision 501994)
>> +++ /usr/ports/lang/gcc8/Makefile   (working copy)
>> @@ -62,7 +62,7 @@
>> 
>> .elif ${ARCH} == powerpc64
>> CONFIGURE_ENV+=UNAME_m="powerpc64"
>> -MAKE_ARGS+=CFLAGS_FOR_TARGET="-O1" CXXFLAGS_FOR_TARGET="-O1" 
>> BOOT_CFLAGS="-O1" # PR235975
>> +#MAKE_ARGS+=   CFLAGS_FOR_TARGET="-O1" CXXFLAGS_FOR_TARGET="-O1" 
>> BOOT_CFLAGS="-O1" # PR235975
>> 
>> .elif ${ARCH} == powerpcspe
>> CONFIGURE_ARGS+=   --with-cpu=8548 --enable-e500_double --without-fp
>> @@ -80,7 +80,7 @@
>> CONFIGURE_ARGS+=--with-build-config=bootstrap-debug
>> ALL_TARGET=bootstrap-lean
>> .endif
>> -INSTALL_TARGET=install-strip
>> +#INSTALL_TARGET=   install-strip
>> .if ${UID} != 0
>> BINMODE=   755
>> .endif
>> 
> 
> I managed to not have poudriere using base/binutils but instead:
> 
> # /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils-poud/usr/bin/ld 
> -v
> GNU ld 2.17.50 [FreeBSD] 2007-07-03
> 
> cc and c++ were as they should have been:
> 
> # /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils-poud/usr/bin/cc 
> -v
> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 
> 8.0.0)
> Target: powerpc64-unknown-freebsd13.0
> Thread model: posix
> InstalledDir: 
> /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils-poud/usr/bin
> 
> # /usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils-poud/usr/bin/c++ 
> -v
> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 
> 8.0.0)
> Target: powerpc64-unknown-freebsd13.0
> Thread model: posix
> InstalledDir: 
>

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

Problem reports for toolch...@freebsd.org that need special attention

[Bug 237975] Add /usr/lib/libgomp.so symlink on Clang architectures

[Bug 237975] Add /usr/lib/libgomp.so symlink on Clang architectures

[Bug 237975] Add /usr/lib/libgomp.so symlink on Clang architectures

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

[Bug 237068] /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion fail elflink.c:2824

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

Re: FYI: Unable to build -r501994 ports' lang/gcc8 on clang 8 based powerpc64 system (no -O1 use): "does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls

20 matches

Site Navigation

Mail list logo

Footer information