Replacing linux' "ld -r" use (was: RFC: Support link with mixed IR/non-IR objects)

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

(Changing the subject mid-conversation to something better
matching.  New readers, please track back to thread start.)

On Tue, 8 May 2012, Cary Coutant wrote:
  Then I wrote:
> > 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.

Oh, right.  Still, I don't know if linker speed is an issue with
the kernel's use, and the default (and most) linker scripts
wouldn't use /INCLUDE/.  Still again, maybe we shouldn't add
kernel-use-limitations in the design. :)
I dunno.  Can we have both?

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

Sure, but older linkers and gccs silently ignoring the added-on
functionality, is to me a stopper issue for that path.

brgds, H-P