From owner-freebsd-current@FreeBSD.ORG Thu Jul 15 11:39:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C250106567B; Thu, 15 Jul 2010 11:39:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2432C8FC15; Thu, 15 Jul 2010 11:39:54 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o6FBdoQJ082478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o6FBdonA043778; Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o6FBdotr043777; Thu, 15 Jul 2010 14:39:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Jul 2010 14:39:50 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20100715113950.GT2381@deviant.kiev.zoral.com.ua> References: <4C246CD0.3020606@freebsd.org> <20100702082754.S14969@maildrop.int.zabbadoz.net> <4C320E6E.4040007@freebsd.org> <20100705171155.K14969@maildrop.int.zabbadoz.net> <4C321409.2070500@freebsd.org> <4C343C68.8010302@freebsd.org> <4C36FB32.30901@freebsd.org> <4C39B0E6.3090400@freebsd.org> <4C39B7DE.3030100@freebsd.org> <4C3EF026.7090706@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8+OS07CeIgZ706fH" Content-Disposition: inline In-Reply-To: <4C3EF026.7090706@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:39:55 -0000 --8+OS07CeIgZ706fH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 15, 2010 at 02:25:26PM +0300, Andriy Gapon wrote: > on 11/07/2010 15:23 Andriy Gapon said the following: > > on 11/07/2010 14:54 Andriy Gapon said the following: > >> For completeness, here is a patch that simply drops the inline assembl= y and the > >> comment about it, and GCC-generated assembly and its diff: > >> http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch > >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s > >> http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff > >> > >> As was speculated above, the only thing really changed is section alig= nment > >> (from 128 to 4). > >=20 > > After making the above analysis I wondered why we require set_pcpu sect= ion > > alignment at all. After all, it's not used as loaded, data from the se= ction > > gets copied into special per-cpu memory areas. So, logically, it's tho= se areas > > that need to be aligned, not the section. > >=20 > > svn log and google quickly pointed me to this excellent analysis and ex= planation > > by bz (thanks again!): > > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > >=20 > > Summary: this alignment is needed to work around a bug in GNU binutils = ld for > > __start_SECNAME placement. > >=20 > > As explained by bz, ld internally generates an equivalent of the follow= ing > > linker script: > > ... > > __start_pcpu_set =3D ALIGN(NN); > > pcpu_set : { > > ... > > } > > __stop_pcpu_set =3D .; > >=20 > > Where NN is an alignment of the first _input_ pcpu_set section found in > > whichever .o file happens to be first. Not the resulting alignment of = pcpu_set > > _output_ section. > > Alignment requirement of input sections is based on largest alignment > > requirement of section's members. So if section is empty then the requ= ired > > alignment is 1. Alignment of output section, if not explicitly overrid= den e.g. > > via linker script, is the largest alignment of the corresponding input = sections. > >=20 > > I think that the problem can be fixed by making ld define __start_SECNA= ME like > > follows: > > ... > > pcpu_set : { > > __start_pcpu_set =3D ABSOLUTE(.); > > ... > > } > > __stop_pcpu_set =3D .; > >=20 > > This way __start_SECNAME would always point to the actual start of the = output > > section. > >=20 > > Here's a patch that implements the idea: > > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > >=20 > > This is similar to what was done upstream: > > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=3D1.30= 6&r2=3D1.307&cvsroot=3Dsrc&f=3Dh > > The code is quite different there, and approach is somewhat different, = but the > > idea is the same - place __start_SECNAME inside the section, not outsid= e it. >=20 > Does anybody see any obvious or non-obvious flaw in the above analysis an= d the > proposed patches? > Does anyone object against me committing the ld patch and some time later= the > pcpu.h patch? >=20 > My plan is to commit the ld patch tomorrow and the pcpu.h patch early nex= t week. >=20 > P.S. > Pro-active testing is welcome! Especially if you have an "unusual" archi= tecture > or use epair or both. >=20 Is new behaviour completely identical to the behaviour of the newer ld ? Even if yes, I think that such changes make potential import of newer binutils harder. --8+OS07CeIgZ706fH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkw+84UACgkQC3+MBN1Mb4hteACdG6JTcLWlpNSmv/+Nly2eBk2t hlEAoJxEY5TdVYFqCXL1jGMco2VIhTFZ =Wh6A -----END PGP SIGNATURE----- --8+OS07CeIgZ706fH--