[PATCH] D77512: [ELF] Add --warn-backrefs-exclude=<glob>

Wed Apr 15 22:01:37 PDT 2020

MaskRay added a comment.

In D77512#1982890 <https://reviews.llvm.org/D77512#1982890>, @psmith wrote:

> Apologies for the delay in responding, just coming back from the Easter break.

Thanks for making suggestions!

> - The user interface for system libraries is often --library or -l, I expect back refs from system libraries to be one of the most common exclusions as these won't be under the users control. Is it worth having --warn-backrefs-exclude mimic that interface. Perhaps even worth --warn-backrefs-exclude-searched that excludes all libraries found via --library. Maybe too blunt for many, but it may be the most common case.

Excluding all libraries via --library can be both coarse and insufficient.

Too coarse: many build systems use -lfoo instead of `path/to/libfoo.a`. The backward reference checking feature is unnecessarily removed for such users.

Insufficient: clang driver passes the full path to some runtime libraries, e.g. `path/to/clang_rt.safestack-x86_64.a` I noticed that library may have a backref problem. More likely it is a problem of our internal (complex) build system, but this may still be a nice example that a system not caring (enough) about GNU linkers can get really difficult to use GNU toolchain at all... I occasionally link programs with gold to cross validate lld. Having a second viable toolchain has a number of advantages. It would be a great loss if projects get really difficult to be linked with GNU linkers.. Making projects overly rely on lld can make it difficult to improve lld as well.
As a positive example, I implemented --no-allow-shlib-undefined to detect compatibility problems. This requires huge efforts cleaning up our internal code base. Thankfully most projects are clean now. Now the backward reference problem is another issue and I noticed that the situation is getting worse but is still fixable.

So really, I created the patch for a selfish purpose but I am hoping it can be general and useful enough and may be adopted by other projects: Android, ChromeOS, Fuchsia (separator; the list on the left are really projects of my company and sometimes their reliance on lld makes it difficult to improve things; as you may have noticed, I got pretty unhappy when Fuchsia people argued against default -z noseparate-code which I think is a clear community favorable choice) FreeBSD, some Linux distributions which use LLVM toolchain.

> - The library name might not be obvious if it is a linker script like libc that expands to several libraries. Not sure how to solve this one.

Yeah, `--warn-backrefs-exclude-searched` can still be insufficient but a generic pattern base blacklist can solve the problem.

> - library filenames may not be unique in some large projects, may need to add the full path to the library. If this already works maybe worth a test.
> 
>   These aren't strong opinions, user interfaces aren't something I've been particular good at.

In the tests, the full path `--warn-backrefs-exclude=%/t2.o` is to check that the full path is considered.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77512