linux-kernel - Re: [Announce] Linux-tiny project revival

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070921062949.GA17131@uranus.ravnborg.org>
Date:	Fri, 21 Sep 2007 08:29:49 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Indan Zupancic <indan@....nu>
Cc:	Rob Landley <rob@...dley.net>, 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, Sep 21, 2007 at 01:06:21AM +0200, Indan Zupancic wrote:
> 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.
Thats a bit unavoidable as the build system works.
__FILE__ is passed the filename supplied as argument to gcc.

Try:
echo "char *s = __FILE__;" > sam.c

gcc -E sam.c
This gives you:
# 1 "sam.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "sam.c"
char *s="sam.c";

gcc -E ~/sam.c
This gives you:
# 1 "/home/sam/sam.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "/home/sam/sam.c"
char *s="/home/sam/sam.c";
 
So __FILE__ expand differently depending on the path on
the gcc command line.
I once posted a patch to fix up on this, especialy for BUG_ON and friends.
The solution was to let kbuild generate the filename and to use
this define in the source code.
But a quick grep for __FILE__ in the kernel source made me chicken out.
Simply too much chrunch at that time to justify it.

Googeling a bit I found it here: http://lkml.org/lkml/2006/7/8/22
The better approach would be to use at least the patch inside
the kernel.
This patch should be easy to update to latest kernel if anyone
is up to play with it.

I recall that there was some problems with the path used.
But I cannot remember the details.
Andrew had some inputs from his testing IIRC and google should
be able to tell the full story.

	Sam





> 
> 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/