https://sourceware.org/bugzilla/show_bug.cgi?id=23411
--- Comment #8 from Cary Coutant <ccoutant at gmail dot com> --- > 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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils