From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7544 Path: news.gmane.org!not-for-mail From: Khem Raj Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] force LTO to be disabled when compiling dlstart.lo Date: Tue, 28 Apr 2015 07:48:23 -0700 Message-ID: References: <1430201554-11359-1-git-send-email-armccurdy@gmail.com> <20150428134317.GL17573@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1430232576 12871 80.91.229.3 (28 Apr 2015 14:49:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 14:49:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7557-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 28 16:49:29 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Yn6ou-0006E3-Dl for gllmg-musl@m.gmane.org; Tue, 28 Apr 2015 16:49:08 +0200 Original-Received: (qmail 25861 invoked by uid 550); 28 Apr 2015 14:49:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25841 invoked from network); 28 Apr 2015 14:49:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=In2H986IDOx78VcR0uKKEMunK7oEzqhWWxsfkNqrifs=; b=VcvLiml8ZDogWA1y7JRSmH3RTyXLoZzbK2qZqLNhdPEQYxbe1VfgcQSqF7tKBhvr8i ObAuN/zCTxfZC9o6mOTwmqcAXrExGrzgCNwfm/f3A0U2d2kmS5yKTVXWKvEUaM7+gI1b vMWQdR1LWB/sym583eOiwGynE3osqaSC1a2aR1XNOdOO7J37seakhvJmKH4wAntfEa3c 1uZUW64np+oRJ80kXxqwkDU++cX5Xrq8b6nbvMnMsJJD6pZLWNdxmHDNwYvP2yYLG2wF LowG0Tl6RgogWA38PCUTK5Vml6JKf+N54zJjxBRDC77+La7Kk3nYlGpU/WCtv0+gsLJB KlNw== X-Received: by 10.42.164.7 with SMTP id e7mr18307334icy.70.1430232533876; Tue, 28 Apr 2015 07:48:53 -0700 (PDT) In-Reply-To: <20150428134317.GL17573@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:7544 Archived-At: On Tue, Apr 28, 2015 at 6:43 AM, Rich Felker wrote: > On Tue, Apr 28, 2015 at 11:35:18AM +0300, Alexander Monakov wrote: >> Hello, >> >> Sorry for not joining the discussion earlier. >> >> Andre, can you specify your GCC and Binutils version? The reason I ask, with >> modern toolchain you shouldn't be seeing the error you reported. The fact >> that _dlstart_c function is used from assembly should have been communicated >> from the linker to the compiler via the "linker plugin". If linker plugin was >> not used, that would explan the problem. >> >> Can you also check if adding '-fuse-linker-plugin' to '-flto' works for you? >> >> For reference, with GCC 4.9 that uses linker plugin for LTO automatically, I >> get the following diagnostics: >> >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: >> error: /tmp/ccxxkwJ8.ltrans0.ltrans.o: requires dynamic R_X86_64_PC32 reloc >> against '_dlstart_c' which may overflow at runtime; recompile with -fPIC >> /tmp/ccxxkwJ8.ltrans0.ltrans.o(.text+0x12): error: undefined reference to >> '_dlstart_c' >> >> Not saying the patch can't go in -- just want to make sure everyone on the >> same page regarding the origin of the problem and GCC LTO capabilities. > with -flto you have to make sure that you use a version of binutils that supports gcc's liblto_plugin. Since version 4.9 gcc produces slim object files that only contain the intermediate representation. In order to handle archives of these objects you have to use the gcc wrappers: gcc-ar, gcc-nm and gcc-ranlib > This seems to be a common problem then. I helped someone on #gcc with > almost the exact same issue doing freestanding work making a > kernel/bare-metal app using LTO a week or so ago. I'm not sure the > linker plugin can solve the problem since it seems to happen for > symbol references *within* a single translation unit (or a combined .o > file produced by ld -r, as in the case of the person on #gcc) which > the linker plugin probably does not track. > > Even if the problem is missing linker plugin though, I think we want > to avoid LTO on these files. It's likely to be very risky since the > code is running in a situation where no function calls, global data > accesses, or symbolic references are possible. Here we really are > asking the compiler to produce asm for us, rather than asking it to > produce an optimized way to get an abstract job done. > > Rich