svn commit: r365836 - head/share/mk

[Jessica Clarke]

> On 17 Sep 2020, at 18:05, Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net> wrote:
> 
>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>> 
>>> Alex Richardson wrote in
>>> <202009171507.08HF7Qns080555 at 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).

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