From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7545 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] force LTO to be disabled when compiling dlstart.lo Date: Tue, 28 Apr 2015 21:41:14 +0300 (MSK) 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=US-ASCII X-Trace: ger.gmane.org 1430246499 9597 80.91.229.3 (28 Apr 2015 18:41:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 18:41:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7558-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 28 20:41:38 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 1YnARo-00024H-Pc for gllmg-musl@m.gmane.org; Tue, 28 Apr 2015 20:41:32 +0200 Original-Received: (qmail 32098 invoked by uid 550); 28 Apr 2015 18:41:26 -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 32080 invoked from network); 28 Apr 2015 18:41:25 -0000 In-Reply-To: <20150428134317.GL17573@brightrain.aerifal.cx> User-Agent: Alpine 2.11 (LNX 23 2013-08-11) Xref: news.gmane.org gmane.linux.lib.musl.general:7545 Archived-At: > 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. I think I see the root cause now. The reference to _dlstart_c is from a GCC asm statement (toplevel in this case), not from a separate assembly file. The toplevel asm is part of LTO "bytecode", so when linker symbol resolution runs, it did not yet have a chance to see the reference from the asm, and GCC is oblivious to the fact (it would need to parse the asm to notice). If the person on #gcc with ld -r was using gcc asm statements as well, that would explain their problem too. So moving the assembly into its own .s file should avoid the issue; adding __attribute__((used)) to _dlstart_c fixes it too; but even then ... > 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. acknowledged. Your call :) Thanks. Alexander