From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2311 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: debloating data, bss Date: Sun, 18 Nov 2012 19:36:44 -0500 Message-ID: <20121119003643.GW20323@brightrain.aerifal.cx> References: <20121118210353.GA4844@brightrain.aerifal.cx> <20121118225912.GN12537@port70.net> 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 1353285416 1169 80.91.229.3 (19 Nov 2012 00:36:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2012 00:36:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2312-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 19 01:37:07 2012 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 1TaFMH-0003qh-Ly for gllmg-musl@plane.gmane.org; Mon, 19 Nov 2012 01:37:05 +0100 Original-Received: (qmail 20310 invoked by uid 550); 19 Nov 2012 00:36:55 -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 20301 invoked from network); 19 Nov 2012 00:36:55 -0000 Content-Disposition: inline In-Reply-To: <20121118225912.GN12537@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2311 Archived-At: On Sun, Nov 18, 2012 at 11:59:12PM +0100, Szabolcs Nagy wrote: > * Rich Felker [2012-11-18 16:03:53 -0500]: > > > > 908 160 12 1080 438 random.o (ex lib/libc.a) > > > > Unfortunately I think random really does have that much state... > > > > interestingly the data segment has different size here > (i386, gcc-4.4.3, default config): > > $ size libc.a |grep random > 841 140 12 993 3e1 random.o (ex libc.a) > > and looking into the code it seems there is indeed 140 bytes > of initialized static data (and 12bytes of zero) Very odd. That's what I counted too, and what the total looks like it should be based on "nm --size". Perhaps gcc is adding some padding/alignment to the data segment? Rich