https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #53 from Justin Hibbits ---
This has been fixed upstream by
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5b9d7a9a647260ba754fbd2a176d37806f15acc8
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #52 from Mark Millard ---
(In reply to Justin Hibbits from comment #51)
I do not know.
if (h->is_weakalias)
{
struct elf_link_hash_entry *def = weakdef (h);
// Here, so that def->def_regular is not based on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #51 from Justin Hibbits ---
Mark, sorry I missed that. It seems to me that a weak alias to an indirect
reference should resolve through the indirect reference. So I think the while
(h->root.type == bfd_link_hash_indirect)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #50 from Mark Millard ---
(In reply to Mark Millard from comment #49)
In case it helps for having debug information around,
in /usr/ports/Mk/bsd.port.mk I use:
STRIP_CMD= ${TRUE}
.endif
DEBUG_FLAGS?= -g
+.if
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #49 from Mark Millard ---
(In reply to Mark Millard from comment #48)
I should have mentioned that print *h->u.alias was
also shown at the last print in the comment.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #48 from Mark Millard ---
(In reply to Justin Hibbits from comment #47)
Dimitry's comment #% indicated that he used printf's.
My comment #8 shows using gdb. Just after the backtrace
I reported (of course your symbol might be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #47 from Justin Hibbits ---
Figuring out what symbol it's choking on would help immensely. Unfortunately,
I haven't found the link between the elf_link_hash_entry and a symbol name yet.
Dimitry, might you know anything?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #46 from Mark Millard ---
(In reply to Justin Hibbits from comment #45)
Okay. Note that beyond eliminating such from what -lc++
pulled in (coment #32 that I fogot to mention), I had to
eliminate such from ports (comment #38
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #45 from Justin Hibbits ---
Yes, I do see those symbols, just as in comment #42. I also see the symbols in
the powerpc64 libraries, and powerpc64 builds llvm60 just fine.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #44 from Mark Millard ---
(In reply to Justin Hibbits from comment #43)
In your environment, does the find command from
comment #42 show the __bss_start in the .dynsym
information in anything involved in the link?
Vs.: have
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Justin Hibbits changed:
What|Removed |Added
CC||jhibb...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #41 from Mark Millard ---
(In reply to Mark Millard from comment #40)
I should have noted: this is based on a gcc 4.2.1
toolchain FreeBSD context, not one of my more modern
toolchain experiments. So:
GNU ld (GNU Binutils)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #40 from Mark Millard ---
(In reply to Dimitry Andric from comment #27)
(In reply to Antoine Brodin from comment #37)
I've not managed to get 32-bit powerpc FreeBSD to build
llvm60 (or other such) using a gcc8/g++8 related
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #39 from Mark Millard ---
(In reply to Mark Millard from comment #38)
Both devel/llvm60 and devel/llvm80 finished in my
powerpc64 context:
[08:14:08] [01] [08:11:48] Finished devel/llvm60 | llvm60-6.0.1_6: Success
. . .
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Antoine Brodin changed:
What|Removed |Added
Assignee|anto...@freebsd.org |toolch...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Antoine Brodin changed:
What|Removed |Added
Version|CURRENT |Latest
Component|bin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Antoine Brodin changed:
What|Removed |Added
Flags|mfc-stable11?, |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #27 from Dimitry Andric ---
Created attachment 204518
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=204518=edit
Remove binutils-do-not-provide-shared-section-symbols patch
(In reply to Antoine Brodin from comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Kubilay Kocak changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #25 from Mark Millard ---
(In reply to Antoine Brodin from comment #23)
https://svnweb.freebsd.org/ports?view=revision=490859
indicates that it got the patch from fedora.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #24 from Mark Millard ---
(In reply to Antoine Brodin from comment #22)
That looks to me like possibly lack of a symbol version script
controlling what is exported from the relevant .so , creating
symbol conflicts.
It appears
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #23 from Antoine Brodin ---
Fedora had the same issue:
https://src.fedoraproject.org/rpms/binutils/c/57a0cd302817a0fff7d529dc8aa7282eef480fad?branch=master
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #22 from Antoine Brodin ---
(In reply to Dimitry Andric from comment #21)
Without the patch, lang/gcc* were failing with this error on at least i386:
/usr/local/bin/ld:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Dimitry Andric changed:
What|Removed |Added
CC||anto...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #20 from Dimitry Andric ---
Ok, bisection shows that your test case is fixed by this commit, which is
unfortunately quite huge due to all the changed test coverage:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #19 from Mark Millard ---
(In reply to Mark Millard from comment #16)
The below is about alternate fixed_seed_override
definitions/declarations in the small example
(not llvm60) and the consequences, in particular
not getting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #18 from Dimitry Andric ---
(In reply to Mark Millard from comment #16)
> The following small source code file and the few steps
> to build/link it produce the message:
>
> # more small_link_failure.cpp
Thanks Mark, this test
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:
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
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 \
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:
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"
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"
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
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:
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Mark Millard changed:
What|Removed |Added
CC||marklmi26-f...@yahoo.com
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #7 from Kubilay Kocak ---
(In reply to Jan Beich from comment #6)
And please reference this PR on that and any related commits
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Jan Beich changed:
What|Removed |Added
CC||jbe...@freebsd.org
--- Comment #6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #5 from Dimitry Andric ---
(In reply to Ed Maste from comment #4)
> Is there an associated GNU binutils ld bug report?
Not yet, I'm working on a small test case. The issue appears to be caused by a
versioned weak symbol:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Kubilay Kocak changed:
What|Removed |Added
CC||trond.endres...@ximalas.inf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #2 from Dimitry Andric ---
Does anybody have a reproducible test case that doesn't involve setting up a
virtual arm box, and going through a complete llvm build? For example, a
tarball containing the .o and .a files which BFD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Kubilay Kocak changed:
What|Removed |Added
Priority|--- |Normal
Status|New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
--- Comment #1 from Kubilay Kocak ---
Created attachment 203437
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203437=edit
devel/llvm60 head-armv6-default (beefy) log
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068
Bug ID: 237068
Summary: /usr/local/bin/ld: BFD (GNU Binutils) 2.30 assertion
fail elflink.c:2824
Product: Base System
Version: CURRENT
Hardware: Any
45 matches
Mail list logo
