bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/24567] Assertion failure in ldlang.c:6868 when compiling with -f


From: amodra at gmail dot com
Subject: [Bug ld/24567] Assertion failure in ldlang.c:6868 when compiling with -flto
Date: Fri, 17 May 2019 11:29:54 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=24567

--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
I reproduced the problem using gcc-8 and openssl from git.

The problem here is caused by libcrypto-lib-armcap.o being loaded twice.  So
why did that happen?  Well, ld sets a flag for object files loaded from the
command line that prevents the object being loaded twice (that's assuming you
don't deliberately mention the object file twice).  For object files within
archives, ld relies on the symbols defined by a particular object file staying
defined, so that another search of the archive armap won't find undefined
symbols satisfied by that object.  Depending on the target, ld also extracts
object files that provide definitions for common symbols.  Again ld expects
that a symbol won't go from defined back to common, but that was exactly what
happened.

libcrypto-lib-armcap.o was a -flto object that defined OPENSSL_armcap_P. 
libcrypto-lib-sha1-armv8.o also defined OPENSSL_armcap_P but as a common
symbol, and this file, being from assembly source, wasn't a -flto object.  The
rules for merging -flto IR symbols and normal object file symbols are a little
complicated, with normal object file symbols generally taking precedence.  In
this case though, ld wrongly overrode the definition from the IR object with
the common symbol from libcrypto-lib-sha1-armv8.o.  A second search of the
archive thus saw libcrypto-lib-armcap.o providing a definition for a common
symbol.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]