From patchwork Fri May 8 21:15:25 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nathan Lynch X-Patchwork-Id: 6367731 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4A253BEEE1 for ; Fri, 8 May 2015 21:18:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6FF0920272 for ; Fri, 8 May 2015 21:18:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 864FA2026F for ; Fri, 8 May 2015 21:18:22 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Yqpcg-0002Ga-Ce; Fri, 08 May 2015 21:15:54 +0000 Received: from relay1.mentorg.com ([192.94.38.131]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Yqpcd-0002EM-TP for linux-arm-kernel@lists.infradead.org; Fri, 08 May 2015 21:15:52 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1YqpcE-00033T-UA from Nathan_Lynch@mentor.com ; Fri, 08 May 2015 14:15:26 -0700 Received: from [127.0.0.1] (147.34.91.1) by SVR-ORW-FEM-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Fri, 8 May 2015 14:15:26 -0700 Message-ID: <554D276D.9040205@mentor.com> Date: Fri, 8 May 2015 16:15:25 -0500 From: Nathan Lynch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stefan Agner Subject: Re: Bulid regression with VDSO enabled References: <391d6fc127b78ef4cbc5443557f0665a@agner.ch> <554CD5F8.10901@mentor.com> <983cc33a8e5704f4281a7d30bbc9d1d2@agner.ch> In-Reply-To: <983cc33a8e5704f4281a7d30bbc9d1d2@agner.ch> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150508_141551_973096_DAD177C2 X-CRM114-Status: GOOD ( 15.32 ) X-Spam-Score: -0.7 (/) Cc: rmk+kernel@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 05/08/2015 11:08 AM, Stefan Agner wrote: > On 2015-05-08 17:27, Nathan Lynch wrote: >> On 05/08/2015 06:13 AM, Stefan Agner wrote: >>> Also, I used the BFD linker by adding LD=${CROSS_COMPILE}ld.bfd to the >>> build command. Interestingly thought, I had the same issue when using >>> gold linker... >> >> When I try this, ld.gold is used regardless. >> >> You can tell by doing and checking for a NT_GNU_GOLD_VERSION note: >> >> $ readelf -n arch/arm/vdso/vdso.so.raw >> >> Displaying notes found at file offset 0x000001bc with length 0x00000040: >> Owner Data size Description >> GNU 0x00000009 NT_GNU_GOLD_VERSION (gold version) >> GNU 0x00000014 NT_GNU_BUILD_ID (unique build >> ID bitstring) >> Build ID: f025409550acb7f955c61d95691291da078e6688 > > Hm, you are right. When deleting moving ld.bfd to ld, which makes the > BFD linker as default, compiling works flawless. > > However, so far LD=${CROSS_COMPILE}ld.bfc seems to work for other build > objects, at least those do not have this note. For instance time.o does > not return anything: > > $ readelf -n arch/arm/kernel/time.o This is just an object file that hasn't been linked, but your general point stands -- LD is honored by other parts of the build. > So it seems to be a vdso.so.raw specific problem not using the specified > linker...? Yes, since it's produced by an invocation of $(CC) which is expected to call the linker implicitly, and this is how the toolchain's default linker ends up getting used even when you set LD on the command line. If I'm not mistaken, implicitly performing a link through the compiler seems to be 1) conventional for all VDSOs, not just ARM's, but 2) unusual for other parts of the kernel build. I suppose it's possible to make arch/arm/vdso/Makefile honor LD, but it would basically entail a rewrite. In the meantime, using -fuse-ld=bfd may suffice: diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile index 8aa791051029..da0ce897edde 100644 --- a/arch/arm/vdso/Makefile +++ b/arch/arm/vdso/Makefile @@ -43,6 +43,7 @@ quiet_cmd_vdsold = VDSO $@ cmd_vdsold = $(CC) $(c_flags) -Wl,-T $(filter %.lds,$^) $(filter %.o,$^) \ $(call cc-ldoption, -Wl$(comma)--build-id) \ -Wl,-Bsymbolic -Wl,-z,max-page-size=4096 \ + $(call cc-option, -fuse-ld=bfd) \ -Wl,-z,common-page-size=4096 -o $@ quiet_cmd_vdsomunge = MUNGE $@