[llvm-bugs] [Bug 43110] New: Detecting symbol conflicts between static libraries

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43110

            Bug ID: 43110
           Summary: Detecting symbol conflicts between static libraries
           Product: lld
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: orivej at gmx.fr
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

Created attachment 22425
  --> https://bugs.llvm.org/attachment.cgi?id=22425&action=edit
--uniqdefs for LLD 8.0.1

Consider an executable built from multiple static libraries. The linker ignores
those objects in the static libraries that do not contribute any needed
symbols. In my experience at Yandex this behavior turned out to be brittle and
error prone. The most common source of errors is when one open source project
copies (parts of) another open source project into its code base (and alters
it, or the original project diverges): if an application depends on both
projects, the linker selects one copy and silently ignores the other which
leads to unexpected behavior at runtime. The second most common source are
small object files that define just a couple of generically named symbols.

One solution to prevent such errors is to link all static libraries with
--whole-archive. However, it is difficult to introduce this into the code base
focused on static linking which expects that unneeded objects are not included
(e.g. when they require the application to supply additional symbols to be used
by the optional object files), and it is costly (either the binary size
increases, or you relink without --whole-archive and the time doubles, or you
link in parallel and the memory doubles).

I would like to propose another solution that seems generally useful and
recommended for all statically built projects. We may want to make sure that a
strongly defined symbol has a single definition across all linker inputs
(including unused objects in static libraries — everything else is handled by
the default -z nomuldefs), but then it would become difficult to intentionally
shadow library symbols by custom overrides (and it is more difficult to
implement in LLD), so we want to ensure the single definition across all static
libraries (which is almost as good if not better). In order to do that we visit
all inputs to build the symbol table as usual, and then we visit libraries
again and add those library objects that define symbols that are already
strongly defined to cause multiple definitions error. (This can be implemented
with essentially zero overhead when there are no multiple definitions.)

One consequence is that it becomes an error to list the same library twice on
the command line (since it is surprisingly difficult to properly deduplicate
input files), so just like --no-whole-archive the new option (currently called
--uniqdefs) needs a counterpart (--no-uniqdefs) to delimit the controlled list
of libraries from the rest.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190825/09c91846/attachment.html>