Re: [Bug gold/23411] Different behavior when linking common symbol statically or to shared object

[Cary Coutant]

> BFD's behavior becomes very problematic with LTO: archive index does not
> distinguish between normal and common definitions, and there's no explicit
> plugin API to check if a definition in IR is "common", so the linker has to
> round-trip via the plugin in a fairly convoluted way to emulate the non-LTO
> behavior :(

Sorry, I don't understand your point. Why does the archive index need
to distinguish between normal and common definitions? I can understand
how it would help, but as long as common symbols are listed in the
archive index, the linker can take a closer look at the archive member
to decide whether or not to include the file.

And the plugin API does provide LDPK_COMMON. What's the "convoluted
round trip" you're referring to?

Hmm, maybe I do see what you're getting at... If the linker decides,
based on the archive index, to include an IR file, it asks the plugin
to provide the symbols for the "closer look", but the API doesn't
provide a way for the linker to then say, "never mind, I don't need
that object after all," in the case where the only symbol of interest
happens to be a common. Is that a problem we really need to worry
about? The only real issue with including an otherwise-unneeded object
is the potential violation of the language's namespace pollution rules
(see below).

> I think it would be prudent to understand *why* ld.bfd wants to override 
> common
> definitions by unpacking archive members with strong definitions. I don't
> expect it's for Fortran - is the real reason stated anywhere?

Common blocks were originally for Fortran, yes, and it's clear that
the linker should include from an archive a BLOCK DATA subprogram that
initializes a common block used elsewhere in the program. The linker
support for this was leveraged for K&R C's tentative definitions, so
the Fortran behavior became the de facto behavior for C.

ANSI C's namespace pollution rules are responsible for the newer
behavior. The scenario we're defending against is when a system
library defines a symbol A that is introduced into the namespace only
if header <A.h> is included, and a program that does not include that
header defines its own symbol A for unrelated purposes. The K&R
behavior would have the library's definition of A override the user's
A if the user's A is a tentative definition. The only way to prevent
this is to avoid the use of K&R-style common for tentative
definitions, or (as on HP-UX) to introduce a second type of "ANSI
common".

The argument for switching back to the K&R rules is that (a) we
haven't implemented the "ANSI common" in the Gnu toolchain, (b) we
need to preserve the old behavior for both Fortran and K&R C code, and
(c) we can achieve strict ANSI compliance through the use of GCC's
-fno-common flag.