From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7482 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: building musl libc.so with gcc -flto Date: Thu, 23 Apr 2015 05:45:20 -0400 Message-ID: <20150423094520.GA17573@brightrain.aerifal.cx> References: <1429742932-6026-1-git-send-email-armccurdy@gmail.com> <20150423022309.GH6817@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 1429782342 14876 80.91.229.3 (23 Apr 2015 09:45:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 09:45:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7495-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 23 11:45:36 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 1YlDhP-0001kL-0Z for gllmg-musl@m.gmane.org; Thu, 23 Apr 2015 11:45:35 +0200 Original-Received: (qmail 14223 invoked by uid 550); 23 Apr 2015 09:45:33 -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 14191 invoked from network); 23 Apr 2015 09:45:32 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7482 Archived-At: On Wed, Apr 22, 2015 at 10:34:40PM -0700, Andre McCurdy wrote: > On Wed, Apr 22, 2015 at 7:23 PM, Rich Felker wrote: > > On Wed, Apr 22, 2015 at 03:48:52PM -0700, Andre McCurdy wrote: > >> Hi all, > >> > >> Below are some observations from building musl libc.so with gcc's -flto > >> (link time optimization) option. > > > > Interesting! > > > >> 1) With today's master (afbcac68), adding -flto to CFLAGS causes the > >> build to fail: > >> > >> | `_dlstart_c' referenced in section `.text' of /tmp/cc8ceNIy.ltrans0.ltrans.o: defined in discarded section `.text' of src/ldso/dlstart.lo (symbol from plugin) > >> | collect2: error: ld returned 1 exit status > >> | make: *** [lib/libc.so] Error 1 > >> > >> Reverting f1faa0e1 (make _dlstart_c function use hidden visibility) > >> seems to be a workaround. > > > > I think the problem is that LTO is garbage collecting "unused" symbols > > before it gets to the step of linking with asm for which there is no > > IR code, thereby losing anything that's only referenced from asm. A > > better workaround might be to define _dlstart_c with a different name > > as a non-hidden function (e.g. call it __dls1) and then make > > _dlstart_c a hidden alias for it via: > > > > __attribute__((__visibility__("hidden"))) > > void _dlstart_c(size_t *, size_t *); > > > > weak_alias(__dls1, _dlstart_c); > > > > If you get a chance to try that, let me know if it works. > > That change does fix the build, but the resulting binary fails to run: > > $ gdb ./lib/libc.so > .... > (gdb) run > Starting program: /home/andre/.../lib/libc.so > > Program received signal SIGILL, Illegal instruction. > 0x56572ab8 in _dlstart () > (gdb) disassemble > Dump of assembler code for function _dlstart: > 0x56572aa0 <+0>: xor %ebp,%ebp > 0x56572aa2 <+2>: mov %esp,%eax > 0x56572aa4 <+4>: and $0xfffffff0,%esp > 0x56572aa7 <+7>: push %eax > 0x56572aa8 <+8>: push %eax > 0x56572aa9 <+9>: call 0x56572aae <_dlstart+14> > 0x56572aae <+14>: addl $0x7864a,(%esp) > 0x56572ab5 <+21>: push %eax > 0x56572ab6 <+22>: call 0x56572ab7 <_dlstart+23> > 0x56572abb <+27>: nop > 0x56572abc <+28>: lea 0x0(%esi,%eiz,1),%esi > End of assembler dump. > (gdb) OK, it looks like the _dlstart_c symbol got removed before linking the asm. What about selectively compiling this file with -fno-lto via something like this in config.mak: src/ldso/dlstart.lo: CFLAGS += -fno-lto > > Also seems rather like what I would expect. Any idea if performance is > > significantly better? It's not very comprehensive but you could try > > libc-bench. > > I modified libc-bench so that it loops though everything in main() ten > times and then ran the same libc-bench binary with each version of > libc.so, sending output to /dev/null. > > The -O3 -flto build seems to be consistently very slightly *slower* > than the non -flto version... That makes the whole thing somewhat less interesting. LTO is probably more interesting for static libc. Rich