[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38197.81.207.0.53.1190329581.squirrel@secure.samage.net>
Date: Fri, 21 Sep 2007 01:06:21 +0200 (CEST)
From: "Indan Zupancic" <indan@....nu>
To: "Rob Landley" <rob@...dley.net>, "Sam Ravnborg" <sam@...nborg.org>
Cc: linux-tiny@...enic.com,
"Michael Opdenacker" <michael@...e-electrons.com>,
"CE Linux Developers List" <celinux-dev@...e.celinuxforum.org>,
"linux kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [Announce] Linux-tiny project revival
On Fri, September 21, 2007 01:18, Rob Landley wrote:
> On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
>> A quick scroll through a vmlinux binary shows that there are quite a
>> lot areas consisting only of some repeated pattern. Mostly 0x00, but
>> also 0x90 and ".GCC: (GNU) 4.2.1.". Getting rid of those would save
>> something between 50 and 100KB.
>
> Worse, if you feed an absolute path to O= when you build the kernel out of
> tree, then it uses absolute paths for all the __FILE__ strings and that makes
> kernel BIIIIIG. (Did that by accident a while back.) Too bad there's no way
> to keep the __FILE__ strings compressed at runtime and gunzip them as needed
> like busybox does with help messages... :)
I suspect that can be fixed by changing the built system. How can using O=
change the source file path anyway? That seems unnecessary.
It seems to be worse, full pathnames are also used when giving a relative path.
(I'm using O=../obj/).
On the other hand, it doesn't seem to cause that much bloat here:
$ strings vmlinux | grep /home/ |wc
119 181 6400
CC'ing Sam Ravnborg, perhaps he has some ideas.
Greetings,
Indan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists