D77522 changed --warn-backrefs to not warn for linking sandwich
problems (-ldef1 -lref -ldef2). This removed lots of false positives.
However, glibc still has some problems. libc.a defines some symbols
which are normally in libm.a and libpthread.a, e.g. __isnanl/raise.
For a linking order -lm -lpthread -lc, I have seen:
// different resolutions: GNU ld/gold select libc.a(s_isnan.o) as the definition backward reference detected: __isnanl in libc.a(printf_fp.o) refers to libm.a(m_isnanl.o) // different resolutions: GNU ld/gold select libc.a(raise.o) as the definition backward reference detected: raise in libc.a(abort.o) refers to libpthread.a(pt-raise.o)
To facilitate deployment of --warn-backrefs, add --warn-backrefs-exclude= so that
certain known issues (which may be impractical to fix) can be whitelisted.
Deliberate choices:
- Not a comma-separated list (--warn-backrefs-exclude=liba.a,libb.a). -Wl, splits the argument at commas, so we cannot use commas. --export-dynamic-symbol is similar.
- Not in the style of --warn-backrefs='*' --warn-backrefs=-liba.a. We just need exclusion, not inclusion. For easier build system integration, we should avoid order dependency. With the current scheme, we enable --warn-backrefs, and indivial libraries can add --warn-backrefs-exclude=<glob> to their LDFLAGS.
Just a drive by observation. Why not --no-warn-backrefs=? Basically the same semantics except --no-warn-backrefs= instead of --warn-backrefs-exclude=