Date: Thu, 17 Sep 2020 18:23:19 +0100 From: Jessica Clarke <jrtc27@freebsd.org> To: rgrimes@freebsd.org Cc: Warner Losh <imp@bsdimp.com>, Alex Richardson <arichardson@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r365836 - head/share/mk Message-ID: <C1895D1E-B3FF-4CE0-8CF1-D8151FEA0D59@freebsd.org> In-Reply-To: <202009171705.08HH5CtE014644@gndrsh.dnsmgr.net> References: <202009171705.08HH5CtE014644@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 17 Sep 2020, at 18:05, Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> = wrote: >=20 >> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <steffen@sdaoden.eu> = wrote: >>=20 >>> Alex Richardson wrote in >>> <202009171507.08HF7Qns080555@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. >>>=20 >>> 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? >>>=20 >>=20 >> 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). >>=20 >> 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. >>=20 >> I doubt you could measure a difference here today. I doubt, honestly, = that >> anybody will notice at all. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C1895D1E-B3FF-4CE0-8CF1-D8151FEA0D59>