Re: RFC: Support link with mixed IR/non-IR objects

[Cary Coutant <ccoutant at google dot com>]

>> A while back, I suggested a solution for forcing the linker to pull
>> members from an archive library, by modifying the linker(s) to
>> recognize a special fake symbol (say, ".FORCE") in the archive symbol
>> table and always link the corresponding object. ar could add a
>> ".FORCE" entry to the archive symbol table for any object that
>> contains some kind of trigger, like a .note section or a
>> .gnu_force_link section.
>
> That'd work. ?It's wartish in that .FORCE might have to be
> global and yet not colliding with other .FORCE symbols and
> also that it requires changes to "ar".

The .FORCE symbol wouldn't actually be in the .o -- it's just a magic
name in the archive symbol table. Even if a .o happened to define a
global named ".FORCE", the worst that would happen is that it always
get linked in. But, yes, it's wartish. There are probably more elegant
ways of accomplishing this, but the fake symbol seemed simplest.

> An alternative that I was thinking of and which doesn't require
> "ar" changes, is to add a new linker option and linker-script
> option to force sections matching a pattern specified by the
> mechanism into the linked object, even if they're only found in
> a static .a archive, similar to what happens with -u for
> symbols. ?Say, (in the script) /INCLUDE/ similar to /DISCARD/,
> just the opposite. :) ?Maybe --include-section=GLOB for the
> command-line option. ?Of course, KEEP() is implied. ?I'm not
> sure existing linker versions emits errors when it's found, so
> maybe tweak the implied syntax so that they do; we don't want
> current linkers to silently ignore it.

The linker doesn't currently look inside any of the .o files unless
it's already selected on for inclusion based on the archive symbol
table. If you make it look inside each archive member, it'll slow the
linker down. That's why I suggested having ar look for whatever
trigger might be in the .o and add the fake symbol to the archive
symbol table.

>> I'd also like to make GCC's __attribute ((used)) attribute create a
>> special section in the .o file that identifies each variable or
>> function tagged as used. That could be used to trigger the force-link
>> from an archive, and can also be used by the linker to prevent garbage
>> collection.
>>
>> Is there any support for this idea?
>
> I'd support it, FWIW. ?It'd overload the "used" attribute, so
> maybe better add a new one, one which gcc can be sorry() about,
> if it hasn't detected support in the linker (existing versions
> will warn on the unrecognized attribute, which is good enough
> IMHO). ?I'd suggest the colors "linked" or "linkused" and
> ".GNU.include" for the section-name, just to trig interest
> through the resulting bikeshed session. :)

Yeah, I was originally thinking of a new attribute, but I haven't
found any use of the "used" attribute where one could reasonably argue
that the point wasn't to keep that symbol from being removed from the
program. Today, it keeps it from being optimized away by the compiler,
but there's little point to that if it just gets optimized away later
-- say by archive library searching or by link-time garbage
collection.

-cary