Date: Thu, 15 Jul 2010 14:39:50 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@freebsd.org> 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] Message-ID: <20100715113950.GT2381@deviant.kiev.zoral.com.ua> In-Reply-To: <4C3EF026.7090706@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100715113950.GT2381>