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

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 8 May 2012, Cary Coutant wrote:
> > Linux can't use "ar" as it is, because it (and gold and gld,
> > when passed an .a) doesn't make sure to include objects with the
> > kernel flavor of cdtors in the final image, and you can't
> > combine several .a into a new .a just by calling "ar".
>
> With thin archives, you *can* combine several archives into one.

Well, there you go, one problem already solved. :)

I was of the impression that you could get filename collisions
with thin archives, but maybe not for the kernel's use. As you
may know, the current process is to create objects (thin
archives) from dir1/dir2/*.o into dir1/dir2/built-in.o (let's
pretend it's .a) and then from dir1/dir2/built-in.a and
dir1/dir3/built-in.a (and more) create dir1/built-in.a and
(repeat for a few deeper levels) use the result at the final
link.

> 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".

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.

> 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. :)

brgds, H-P