[PATCH] D101996: [LLD] Improve reporting of unresolved symbols in shared libraries

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 6 09:28:24 PDT 2021


MaskRay added a comment.

> The current implementation checks the file where the symbol was seen for the first time. That might be a file that does not meet the requirements for reporting, e.g. it might have some DT_NEEDED missed or it might be a relocatable file that also references the symbol. As a result, the actual issue is not detected, the error is not reported, and an incorrect output file is generated whereas it should not.

"it might have some DT_NEEDED missed" -> We don't recursively load DT_NEEDED so this is expected. This patch doesn't address the issue as well. The description may give a false impression that the issue is tackled.

I think the issue is entirely: an undefined symbol in a regular object file shadows an undefined symbol in a shared object, and that regular object file doesn't get diagnosed (`-z defs`) because --gc-sections discards the referencing sections.
You can amend the description to mention this. Are there other types of missing --no-allow-shlib-undefined diagnostics?



================
Comment at: lld/test/ELF/unresolved-in-dso.ll:1
+# REQUIRES: x86
+
----------------
Can this be placed in `allow-shlib-undefined.s` or named similar to that file?


================
Comment at: lld/test/ELF/unresolved-in-dso.ll:14
+
+.globl _start
+_start:
----------------
You can place %t.o and %ta.o in the same object file.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101996/new/

https://reviews.llvm.org/D101996



More information about the llvm-commits mailing list