From owner-svn-src-head@freebsd.org Thu Sep 17 19:03:54 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 75CE83EA341 for ; Thu, 17 Sep 2020 19:03:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BsmbF3tpVz4SKl for ; Thu, 17 Sep 2020 19:03:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72f.google.com with SMTP id w12so3405304qki.6 for ; Thu, 17 Sep 2020 12:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AyzofWIGY1+fmXOA3bVnhqKdBLqWULs1086sw6V3x+c=; b=kGKXGIiOt/N/NQPzhvP0SiSoampr+PKFGBQfH1Os4vh4FuLLZvairbQiy+QxEfmfpC HUWHRH/mNSswyzgHk/DVx5YZJBnvoE01GNs6pSu4KBzNWcI0PXeY2/7DyZK4f/Q0F1Qe yNk15F6xDZ5VsEF2m4AvSbjDZ80ltlU+UaXLmUaNnRyeIjoRhLntkbMDkOL35t4C0diC XHiPR1QhIkciRYtOtxKT5uL6wQjEov+b8T0fDiB81EtgecoDKw107pAFE3EYiVBNtERg SWUO8xZi8lZTNdyTJpQVcWL8DysNwgA14F7x6CueuJcTDB40ew+dZY63CcVLH/qjfmC1 lxUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AyzofWIGY1+fmXOA3bVnhqKdBLqWULs1086sw6V3x+c=; b=Ci62ksNtB6DrenmXJME+f3ygyoGP+hqm0Yvd+TAkZ0TIEASi8xtGU6Bh5ESA/n0nKW Fh2o1g1eY7VPhiIAowYcVnohYQqHeb75/181SuwnTU+sWvkJ1kUvlg2nT7aThbI69J/J G0HGGdbLZcOvfyR6+0kdbgp8jdEBhU36mq8I2ph7AZAnxAB2sHYfltYbuN7eaKhko8/y QeRL0yAmuQVvrqq1xSk/xuHDj6di2XO0sK7IH7vPcXUyFBBqFgmRzq0PQho8t/tkEvYX Y9Z7WxpY9fCcJ2UkA0zOphCktax2uGO1wHsUvs2lGv06dstXLih3H/kBAy/LASKNJpNV dT8A== X-Gm-Message-State: AOAM532ZL4QHtkl+IeamjR5i6MW/bNhK1ZrVJGP40jOEjZEtXZSdequs 3ZFQYgUzkr6hDB5R6RiH9wdMG6uOvshR+sSMulimDQ== X-Google-Smtp-Source: ABdhPJwdqd0dgsoMo8JgWcL+yJXY9AGw0TbXmXG48+wQTyJS1TedM/ALWuCMuAhOLdjB1kGx5RnLXxOGYLN48FOPtU8= X-Received: by 2002:a05:620a:2006:: with SMTP id c6mr27620524qka.240.1600369432211; Thu, 17 Sep 2020 12:03:52 -0700 (PDT) MIME-Version: 1.0 References: <202009171705.08HH5CtE014644@gndrsh.dnsmgr.net> <307760E0-1208-4F4C-AD7D-9E0A3C1B3A3B@freebsd.org> In-Reply-To: <307760E0-1208-4F4C-AD7D-9E0A3C1B3A3B@freebsd.org> From: Warner Losh Date: Thu, 17 Sep 2020 13:02:18 -0600 Message-ID: Subject: Re: svn commit: r365836 - head/share/mk To: Jessica Clarke Cc: "Rodney W. Grimes" , Alex Richardson , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4BsmbF3tpVz4SKl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=kGKXGIiO; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.23 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[svn-src-head]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.89)[-0.894]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.946]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.39)[-0.387]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72f:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 19:03:54 -0000 On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke wrote: > > On 17 Sep 2020, at 18:23, Jessica Clarke wrote: > > > >> On 17 Sep 2020, at 18:05, Rodney W. Grimes > wrote: > >> > >>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso > 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 > >