From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 12:21:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DEC1065670; Sun, 11 Jul 2010 12:21:42 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 05AF48FC19; Sun, 11 Jul 2010 12:21:40 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27402; Sun, 11 Jul 2010 15:21:38 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OXvXO-000DnP-B6; Sun, 11 Jul 2010 15:21:38 +0300 Message-ID: <4C39B751.8070804@freebsd.org> Date: Sun, 11 Jul 2010 15:21:37 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: "Bjoern A. Zeeb" , freebsd-hackers@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> In-Reply-To: <4C39B0E6.3090400@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , Konstantin Belousov , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 12:21:42 -0000 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 sections 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: 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. My testing shows the expected results. What do you think? -- Andriy Gapon