> On 17 Sep 2020, at 18:23, Jessica Clarke <jrt...@freebsd.org> wrote: > >> On 17 Sep 2020, at 18:05, Rodney W. Grimes <free...@gndrsh.dnsmgr.net> wrote: >> >>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <stef...@sdaoden.eu> wrote: >>> >>>> Alex Richardson wrote in >>>> <202009171507.08hf7qns080...@repo.freebsd.org>: >>>> |Author: arichardson >>>> |Date: Thu Sep 17 15:07:25 2020 >>>> |New Revision: 365836 >>>> |URL: https://svnweb.freebsd.org/changeset/base/365836 >>>> | >>>> |Log: >>>> | Stop using lorder and ranlib when building libraries >>>> | >>>> | Use of ranlib or lorder is no longer necessary with current linkers >>>> | (probably anything newer than ~1990) and ar's ability to create an >>>> object >>>> | index and symbol table in the archive. >>>> | Currently the build system uses lorder+tsort to sort the .o files in >>>> | dependency order so that a single-pass linker can use them. However, >>>> | we can use the -s flag to ar to add an index to the .a file which makes >>>> | lorder unnecessary. >>>> | Running ar -s is equivalent to running ranlib afterwards, so we can >>>> also >>>> | skip the ranlib invocation. >>>> >>>> That ranlib thing yes (for long indeed), but i have vague memories >>>> that the tsort/lorder ordering was also meant to keep the things >>>> which heavily interdepend nearby each other. (Luckily Linux >>>> always had at least tsort available.) >>>> This no longer matters for all the platforms FreeBSD supports? >>>> >>> >>> tsort has no notion of how dependent the modules are, just an order that >>> allows a single pass through the .a file (otherwise you'd need to list the >>> .a file multiple times on the command line absent ranlib). That's the >>> original purpose of tsort. tsort, lsort, and ranlib all arrived in 7th >>> edition unix on a PDP-11, where size was more important than proximity to >>> locations (modulo overlays, which this doesn't affect at all). >>> >>> There were some issues of long vs short jumps on earlier architectures that >>> this helped (since you could only jump 16MB, for example). However, there >>> were workarounds for this issue on those platforms too. And if you have a >>> program that this does make a difference, then you can still use >>> tsort/lorder. They are still in the system. >>> >>> I doubt you could measure a difference here today. I doubt, honestly, that >>> anybody will notice at all. >> >> The x86 archicture has relative jmps of differning lengths, even in long mode >> there is support for rel8 and rel32. > > That's irrelevant though for several reasons: > > 1. The compiler has already decided on what jump instructions to use based on > the requested code model (unless you're on RISC-V and using GNU bfd ld as > that supports linker relaxations that actually delete instruction bytes). > > 2. The linker is still free to reorder input sections however it likes, it > doesn't have to follow the order of the input files (and the files within > any archive).
Hm actually that's only true for archives; it needs to respect the order of files on the command line for things like crti.o to work. But regardless, the other points (and this one, partially) still hold. > 3. If you care about those kinds of optimisations you should use link-time > optimisation which will likely do far more useful things than just optimise > branches, but again isn't constrained by the order of the input files, it > can lay out the code exactly how it wants. > > Not to mention that this is just a topological sort, not a clustering sort. > > Jess _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
