Makefile: Link in {simple,lazy}-diagnostic-path.o [PR116143]

Some of the plugin.exp tests FAIL in --enable-checking=release builds while
they succeed in --enable-checking=yes builds.
Initially I've changed some small simple out of line methods into inline ones
in the header, but the tests kept failing, just with different symbols.

The _ZN22simple_diagnostic_path9add_eventEmP9tree_nodeiPKcz symbol (and the
others too) are normally emitted in simple-diagnostic-path.o, it isn't some
fancy C++ optimization of classes with final method or LTO optimization.

The problem is that simple-diagnostic-path.o is like most objects added into
libbackend.a and we then link libbackend.a without -Wl,--whole-archive ...
-Wl,--no-whole-archive around it (and can't easily, not all system compilers
and linkers will support that).
With --enable-checking=yes simple-diagnostic-path.o is pulled in, because
selftest-run-tests.o calls simple_diagnostic_path_cc_tests and so
simple-diagnostic-path.o is linked in.
With --enable-checking=release self-tests aren't done and nothing links in
simple-diagnostic-path.o, because nothing in the compiler proper needs
anything from it, only the plugin tests.

Using -Wl,-M on cc1 linking, I see that in --enable-checking=release
build
analyzer/analyzer-selftests.o
digraph.o
dwarf2codeview.o
fibonacci_heap.o
function-tests.o
hash-map-tests.o
hash-set-tests.o
hw-doloop.o
insn-peep.o
lazy-diagnostic-path.o
options-urls.o
ordered-hash-map-tests.o
pair-fusion.o
print-rtl-function.o
resource.o
rtl-tests.o
selftest-rtl.o
selftest-run-tests.o
simple-diagnostic-path.o
splay-tree-utils.o
typed-splay-tree.o
vmsdbgout.o
aren't linked into cc1 (the *test* for obvious reasons of not doing
selftests, pair-fusion.o because it is aarch64 specific, hw-doloop.o because
x86 doesn't have doloop opts, vmsdbgout.o because not on VMS).

So, the question is if and what from digraph.o, fibinacci_heap.o,
hw-doloop.o, insn-peep.o, lazy-diagnostic-path.o, options-urls.o,
pair-fusion.o, print-rtl-function.o, resource.o, simple-diagnostic-path.o,
splay-tree-utils.o, typed-splay-tree.o are supposed to be part of the
plugin API if anything and how we arrange for those to be linked in when
plugins are enabled.

The following patch just adds unconditionally the
{simple,lazy}-diagnostic-path.o objects to the link lines before libbackend.a
so that their content is available to plugin users.

2025-02-27  Jakub Jelinek  <jakub@redhat.com>

	PR testsuite/116143
	* Makefile.in (EXTRA_BACKEND_OBJS): New variable.
	(BACKEND): Use it before libbackend.a.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c159825e62c8d690b4800c1fb7452b8b852f7b4d..10a42cb1dd7d346e62178aca2052795731af2189 100644 (file)
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1904,8 +1904,12 @@ ifeq (@enable_libgdiagnostics@,yes)
 ALL_HOST_OBJS += $(libgdiagnostics_OBJS) $(SARIF_REPLAY_OBJS)
 endif
 
-BACKEND = libbackend.a main.o libcommon-target.a libcommon.a \
-       $(CPPLIB) $(LIBDECNUMBER)
+# libbackend.a objs that might not be in some cases linked into the compiler,
+# yet they are supposed to be part of the plugin ABI.  See PR116143.
+EXTRA_BACKEND_OBJS = simple-diagnostic-path.o lazy-diagnostic-path.o
+
+BACKEND = $(EXTRA_BACKEND_OBJS) libbackend.a main.o libcommon-target.a \
+       libcommon.a $(CPPLIB) $(LIBDECNUMBER)
 
 # This is defined to "yes" if Tree checking is enabled, which roughly means
 # front-end checking.