[llvm-bugs] [Bug 43554] New: Add a new option to ignore undefined symbols in DSO

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Oct 4 00:26:41 PDT 2019


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

            Bug ID: 43554
           Summary: Add a new option to ignore undefined symbols in DSO
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: ruiu at google.com
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

lld used to ignore undefined symbols in DSOs, but I changed that behavior in
https://reviews.llvm.org/rL325849 to improve compatibility with GNU linkers.
That resulted in an unintended consequence on Android.

First, let me explain why I made lld to try to resolve undefined symbols in
DSO. The current lld's behavior is as follows.

  1. When you are creating a DSO, Unix linkers traditionally allow undefined
symbols to remain. Remaining undefined symbols from input object files are left
as undefined symbols in a DSO.

  2. When you are creating an executable, Unix linkers traditionally try to
resolve all undefined symbols for all input files including DSOs. Undefined
symbols in DSOs that cannot be resolved by any other DSOs or by a main
executable are usually detected at this stage. If the linker doesn't do this,
such undefined symbols would be detected at dynamic-link time (i.e. you can't
find them until you try to run a program), which is much more inconvenient.

I think the above (1) and (2) are coherent and make sense. Being said that,
that doesn't seems like the only approach that make sense. Think about the
following feature combination.

  3. Do not allow undefined symbols in DSOs. This can be achieved by passing
`--no-undefined` option to the linker along with `--shared`.

  4. Do not try to resolve undefined symbols in DSOs when creating an
executable, assuming all DSO undefined symbols will be resolved successfully at
runtime.

It seems (3) and (4) are also coherent and make sense.

On Android, `--no-undefined` is actually always passed to the linker. So, on
Android, we don't have to try to resolve DSO undefined symbols at link-time.

The problem is that it seems like we don't have an option to achieve (4)'s
behavior. Maybe we should add a new option for that. What do you think?

-- 
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/20191004/9f440625/attachment-0001.html>


More information about the llvm-bugs mailing list