The branch time for the 2.44 release is approaching

[Alan Modra]

On Tue, Jan 07, 2025 at 09:10:18PM +0000, Sam James wrote:
> I would love to see
> https://inbox.sourceware.org/binutils/20240905111452.2554-1-hjl.tools@gmail.com/
> in.
> 
> I have been using it locally for several months now. It is not yet in
> the Gentoo patchset, though. We can add it in and then report back
> results for the next Binutils cycle if preferred.

I'm not strongly against this patch for ld -r, but on the other hand I
don't intend to review it.  That's because I take a dim view of using
ld -r just to package a group of object files.  People don't seem to
realise that ld -r has quite a lot of negative consequences, and as
far as I'm concerned a problem with ld -r and a mix of LTO and non-LTO
objects making this obvious is actually a good thing..

Some of the ld -r negatives that spring to mind are:
1) Combining sections prematurely, in some cases resulting in sections
that are too large to handle at final link.  eg. code that is so large
that branches won't reach to linker inserted trampolines.  Most of
these issues don't affect x86, so I suppose it isn't surprising that
people don't know this.
2) Unwanted code locality changes even when -ffunction-sections
-fdata-sections is used to avoid most of (1).  eg. multiple static
functions called "setup" will be moved together, rather than being
near their callers, which potentially increases processor cache
pressure.
3) Needing to use --gc-sections, which can leave unwanted debug info
and other data for functions removed.  Those functions and their debug
info would not have been present if an archive with fine enough
granularity of objects had been used for packaging.  (And of course
the user doesn't needlessly use --whole-archive when linking.)

-- 
Alan Modra