Plugin tests in ld testsuite

[Stephen Casner]

I'm still working on the plugin tests in the ld testsuite for the
pdp11-aout target.  The test "plugin claimfile lost symbol" passes
because symbols for the claimed file are not loaded at all.  But the
next test, "plugin claimfile replace symbol" fails because the test
expects the "_func" symbol to still be undefined even though the link
includes the following option:  -plugin-opt sym:_func::0:0:0

So my first question is what are the semantics of that option?  The
zeros mean LDPK_DEF (definition), LDPV_DEFAULT (visibility), and size
0.  So I would expect this option to make the symbol defined.

I did manage to build binutils and gcc for the arm-none-eabi target
that passes this test, that is, leaving the symbol undefined.
Comparing the execution for that target with pdp11-aout I found what
appears to be the significant difference.  The plugin code creates a
dummy BFD to contain the symbol and then replaces the original BFD for
the claimed file with that dummy BFD which includes the flag
BFD_PLUGIN.  Then the plugin code calls bfd_make_readable() which
calls bfd_check_format_matches() which calls xxx_object_p for the
appropriate target.

In the case of elf_object_p() there is a comment, "We have to avoid
leaving any side effects in ABFD, or any data it points to (like
tdata), if the file does not match the target vector."  In particular,
the flag bits are preserved including BFD_PLUGIN.  Later, in
_bfd_generic_link_add_one_symbol() the symbol "func" is set to type
bfd_link_hash_defined, but in bfd_elf_final_link() the type is set to
bfd_link_hash_undefined because BFD_PLUGIN is set, as explained by the
comment "If a plugin symbol is referenced from a non-IR file, mark the
symbol as undefined."  That's how the test passes for the
arm-none-eabi target.

But in the case of aout_16_some_object_p() in pdp11.c the target is
more or less assumed to match and the incoming flag bits are
completely overwritten.  As for ELF, the type of the symbol is set to
bfd_link_hash_defined in _bfd_generic_link_add_one_symbol().  Then in
aout_16_final_link() there is no code to look for the BFD_PLUGIN flag
anyway, so the symbol is treated as defined and the test fails.

Now, you could just say that the pdp11-aout code is broken, but the
code is the same in aoutx.h for the other a.out formats and I don't
see any code in plugin.exp to exclude them.  Do all aout formats get
an unexpected FAIL for the plugin tests?

Should the pdp11-aout target be fixed to properly support plugins, or
is there no point and it should just be configured to disable plugin
support?

                                                        -- Steve