Hello, On Thu, 27 Oct 2022, Masahiro Yamada wrote: > > To be precise: I know of no linker (outside LTO-like modes) that processes > > archives in a different order than first-to-last-member (under > > whole-archive), but that's not guaranteed anywhere. So relying on > > member-order within archives is always brittle. > > The objects in an archive are linked first-to-last-member for a long time. > This is the assumption which we have relied on for a long time. Sure, that doesn't mean it's guaranteed, for this I'm just devils advocate. As I said, it's the mode of operation of all currently existing linkers I know, so for the forseeable future you can continue to rely on it. But as soon as LTO enters the picture that all breaks down, as you see here. Consider how LTO works, the granularity of shuffling stuff around is the functions of all inputs, not the object files. So, even if you say obj1.o obj2.o on the link command line, and supposed there are two functions in each of obj1 and obj2, then it may just so happen that LTO partitions the program such that it ends up with partitions part1 : obj1:foo obj2:bar part2 : obj1:bar obj2:foo now, suddenly there is no order between part1 and part2 anymore that would faithfully represent the original order between obj1 and obj2 functions. Of course the partitioning algorithm could be changed, but that would limit the effectiveness of LTO. > We assume the initcall order is preserved. > The call order within each of core_initcall, arch_initcall, > device_initcall, etc. > is the order of objects in built-in.a, in other words, > the order they appear in Makefiles. If you rely on relative order of these, then you will probably see interesting effects in LTO mode eventually. > So, this is happening on (not-upstreamed-yet) GCC LTO only? I don't know. As any kind of whole-program transformations is in principle cross-file on per-function basis (that's the whole purpose) I would imagine that you can see these effects in all compilers, if you try hard enough. > > There are only two ways of guaranteeing an ordering: put non-LTO-.o files > > at certain places of the link command, or, better, use a linker script to > > specify an order. > > The objects directly given in the command line are linked in the same order, > even under LTO mode. Is this what you mean? If they don't contain LTO code then yes, they are linked in exactly the given order. If they do, they become part of the LTO blob whose ordering isn't precisely influenced by cmdline order. > Any documentation about that? I think so, but I can't point my finger to anything. Several parts of the toolchain rely on that (so the kernel is not alone), but those are either carefully avoiding LTO or using other ordering means like linker script to achieve what they need. Ciao, Michael.
