Date: Thu, 17 Sep 2020 13:02:18 -0600 From: Warner Losh <imp@bsdimp.com> To: Jessica Clarke <jrtc27@freebsd.org> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, 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: <CANCZdfqxXn0o2tYTXWpKPTQpc9iHp7DzFH-BSghdy%2BP9N9PXJg@mail.gmail.com> In-Reply-To: <307760E0-1208-4F4C-AD7D-9E0A3C1B3A3B@freebsd.org> References: <202009171705.08HH5CtE014644@gndrsh.dnsmgr.net> <C1895D1E-B3FF-4CE0-8CF1-D8151FEA0D59@freebsd.org> <307760E0-1208-4F4C-AD7D-9E0A3C1B3A3B@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke <jrtc27@freebsd.org> wrote: > > On 17 Sep 2020, at 18:23, Jessica Clarke <jrtc27@freebsd.org> wrote: > > > >> On 17 Sep 2020, at 18:05, Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> > wrote: > >> > >>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <steffen@sdaoden.eu> > wrote: > >>> > >>>> 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. > >>>> > >>>> 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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqxXn0o2tYTXWpKPTQpc9iHp7DzFH-BSghdy%2BP9N9PXJg>