svn commit: r365836 - head/share/mk
Jessica Clarke
jrtc27 at freebsd.org
Thu Sep 17 17:25:58 UTC 2020
> 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.
>
> Jess
More information about the svn-src-head
mailing list