linux-kernel - Re: [PATCH] x86: unify x86 Makefile(s)

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]

Date:	Sun, 30 Dec 2007 03:00:51 +0100
From:	Andi Kleen <ak@...e.de>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: unify x86 Makefile(s)

> Without inlining the maxmimum stack usage inside foobar() is
> max(stack usage foo(), stack usage bar()). [1]

It's a little more complicated. gcc 4.x (not sure which x, might 0) 
is clever enough to not use max() stack, but only use the stack for the 
different scopes as needed similar as when the calls weren't inlined. 
But gcc 3 didn't do that.

> With foo() and bar() inlined (-funit-at-a-time also enables 
> -finline-functions-called-once), the maxmimum stack usage inside 
> foobar() is sum(stack usage foo(), stack usage bar()). And this
> worst case is the area where gcc 4 is much better than gcc 3.4.

Yes exactly.  If the functions weren't inlined the problem wouldn't
occur because the stack sizes do not add up in the same dynamic call chain. 
Thus a few statetic noinlines will fix it.

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