On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke <jrt...@freebsd.org> wrote:
> > On 17 Sep 2020, at 18:23, Jessica Clarke <jrt...@freebsd.org> wrote: > > > >> On 17 Sep 2020, at 18:05, Rodney W. Grimes <free...@gndrsh.dnsmgr.net> > wrote: > >> > >>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso <stef...@sdaoden.eu> > wrote: > >>> > >>>> Alex Richardson wrote in > >>>> <202009171507.08hf7qns080...@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 > > _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
