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 assembly > >> 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 alignment > >> (from 128 to 4). > > > > After making the above analysis I wondered why we require set_pcpu section > > alignment at all. After all, it's not used as loaded, data from the section > > gets copied into special per-cpu memory areas. So, logically, it's those > > areas > > that need to be aligned, not the section. > > > > svn log and google quickly pointed me to this excellent analysis and > > explanation > > by bz (thanks again!): > > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > > > > Summary: this alignment is needed to work around a bug in GNU binutils ld > > for > > __start_SECNAME placement. > > > > As explained by bz, ld internally generates an equivalent of the following > > linker script: > > ... > > __start_pcpu_set = ALIGN(NN); > > pcpu_set : { > > ... > > } > > __stop_pcpu_set = .; > > > > 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 required > > alignment is 1. Alignment of output section, if not explicitly overridden > > e.g. > > via linker script, is the largest alignment of the corresponding input > > sections. > > > > I think that the problem can be fixed by making ld define __start_SECNAME > > like > > follows: > > ... > > pcpu_set : { > > __start_pcpu_set = ABSOLUTE(.); > > ... > > } > > __stop_pcpu_set = .; > > > > This way __start_SECNAME would always point to the actual start of the > > output > > section. > > > > Here's a patch that implements the idea: > > http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch > > > > This is similar to what was done upstream: > > http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306&r2=1.307&cvsroot=src&f=h > > The code is quite different there, and approach is somewhat different, but > > the > > idea is the same - place __start_SECNAME inside the section, not outside it. > > Does anybody see any obvious or non-obvious flaw in the above analysis and the > proposed patches? > Does anyone object against me committing the ld patch and some time later the > pcpu.h patch? > > My plan is to commit the ld patch tomorrow and the pcpu.h patch early next > week. > > P.S. > Pro-active testing is welcome! Especially if you have an "unusual" > architecture > or use epair or both. >
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.
pgpTCQwf8PSpI.pgp
Description: PGP signature