From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2779 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 2/3] Have different definitions of __pthread_tsd_main agree in size Date: Mon, 11 Feb 2013 14:09:07 +0100 Message-ID: <20130211130906.GE6181@port70.net> References: <1360535367.23424.466.camel@eris.loria.fr> <20130211003158.GP20323@brightrain.aerifal.cx> <1360568420.23424.521.camel@eris.loria.fr> <20130211112237.GB6181@port70.net> <20130211120816.GC6181@port70.net> <1360587084.9132.83.camel@eris.loria.fr> 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 1360588159 984 80.91.229.3 (11 Feb 2013 13:09:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 13:09:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2780-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 11 14:09:38 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U4t8b-00007K-SU for gllmg-musl@plane.gmane.org; Mon, 11 Feb 2013 14:09:37 +0100 Original-Received: (qmail 1511 invoked by uid 550); 11 Feb 2013 13:09:18 -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 1503 invoked from network); 11 Feb 2013 13:09:18 -0000 Content-Disposition: inline In-Reply-To: <1360587084.9132.83.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2779 Archived-At: * Jens Gustedt [2013-02-11 13:51:24 +0100]: > > and in case of static linking -fdata-sections > > and -ffunction-sections just makes the elfheader > > bigger and the linking slower (sum size of sections > > may be a bit smaller or bigger because of alignment > > things) > > Still I have good experience by using it on another library that > defines a lot of weak symbols that aren't used. > i've just tried it and the .a just got bigger and size reports minimal difference probably due to alignment differences, which does not matter $ size libc.a.sections |awk '{s+=$4}END{print s}' 410638 $ size libc.a |awk '{s+=$4}END{print s}' 410698 > The only real problem I have for libmusl.so is "environ", as of my > other patch. There is probably a good reason that this is made > weak. But why must it be realized as an alias? Wouldn't it be > sufficient to just have it as a weak symbol? something like > > // implementation header file > extern char **__environ __attribute__((__weak )); > > //__environ.c > char **environ __attribute__((__weak )) = 0; > weak_alias(environ, ___environ); > weak_alias(environ, __environ); > weak_alias(environ, _environ); > there are posix requirements for environ so it must be weak i'm not sure about the alias though > > so these flags may be useful for building .so > > As I said in my previous mail: > > > Also I observed that the .so when compiled with -O3 and -flto is > > smaller than with the default build options. > > this is true even without the gc-section stuff. So this is perhaps a > thing to consider. > yes, it is known but before adding -flto the code should be audited for correctness (there might be missing barriers where the code works now because without lto the optimizer cannot reorder code around extern functions, this probably affects math functions that access fenv, note that c99 FENV_ACCESS pragma is not respected by gcc and if float operations are reordered around fe* functions the behaviour changes) and of course all these flags are fairly recent so they need configure script changes (and they might be broken so they need testing)