svn commit: r365836 - head/share/mk

[Alexander Richardson]

On Thu, 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.

However, unless you have linker relaxations (e.g. RISC-V) the compiler
has to emit the large size anyway since the linker won't replace a
32-bit immediate with an 8-bit one since that changes all later
offsets.

Alex