linux-kernel - Re: [patch] x86: phase out forced inlining

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 4 Mar 2008 00:00:31 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Adrian Bunk <bunk@...nel.org>, Sam Ravnborg <sam@...nborg.org>,
	Alexey Starikovskiy <aystarik@...il.com>, lenb@...nel.org,
	astarikovskiy@...e.de, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch] x86: phase out forced inlining

On Tue, 4 Mar 2008 08:32:48 +0100 Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > urgh.  This will cause whatever problem 
> > 4507a6a59cfc6997e532cd812a8bd244181e6205 fixed five years ago to 
> > resurface for incautious gcc-3.x users.
> 
> hm, commit 4507a6a59cfc6997e532cd812a8bd244181e6205 does not exist:
> 
>   fatal: bad object 4507a6a59cfc6997e532cd812a8bd244181e6205

This was 2.5.x - you'll need to look in the historical-git tree.

Here it is:



: commit 4507a6a59cfc6997e532cd812a8bd244181e6205
: Author: akpm <akpm>
: Date:   Tue Mar 11 07:42:00 2003 +0000
: 
:     [PATCH] work around gcc-3.x inlining bugs
:     
:     Force inlining even when gcc-3.x is too confused to do it for us.
:     
:     BKrev: 3e6d9348GA9aKzeN-bjzQzMMt85t8g
: 
: diff --git a/include/linux/compiler.h b/include/linux/compiler.h
: index e92f472..a28d0d5 100644
: --- a/include/linux/compiler.h
: +++ b/include/linux/compiler.h
: @@ -1,6 +1,12 @@
:  #ifndef __LINUX_COMPILER_H
:  #define __LINUX_COMPILER_H
:  
: +#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
: +#define inline		__inline__ __attribute__((always_inline))
: +#define __inline__	__inline__ __attribute__((always_inline))
: +#define __inline	__inline__ __attribute__((always_inline))
: +#endif
: +
:  /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
:     a mechanism by which the user can annotate likely branch directions and
:     expect the blocks to be reordered appropriately.  Define __builtin_expect
: 

I was very bad about changelogging that one.  I do remember there was a bit
of to-and-fro before we decided to do it this way.  Some googling would be
needed.  

> but i suspect it must be something along the lines of the known problem 
> of really old gcc versions creating huge stackframes?

iirc gcc was failing to inline functions which we'd marked `inline' and it
was generating poorer code as a result.  It might also have been generating
an out-of-line copy for each compilation unit which called the inline (it
would have to do this?)

> Those pristine gcc 
> versions were practically unusable for distro kernels anyway (and were 
> patched by distros) - but i have no problem with restricting this 
> feature to gcc4x. gcc4x creates more compact -Os code too, so it's 
> recommended for smaller image sizes.

yup.

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