svn commit: r365836 - head/share/mk
Warner Losh
imp at bsdimp.com
Thu Sep 17 19:03:54 UTC 2020
On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke <jrtc27 at freebsd.org> wrote:
> > On 17 Sep 2020, at 18:23, Jessica Clarke <jrtc27 at freebsd.org> wrote:
> >
> >> 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).
>
> 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.
>
Yea. I doubt you'd be able to measure a difference on anything in our tree.
Warner
> Jess
>
>
More information about the svn-src-all
mailing list