* Build failures with gcc 4.5 and older @ 2018-08-14 17:09 Guenter Roeck 2018-08-14 17:20 ` Linus Torvalds ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Guenter Roeck @ 2018-08-14 17:09 UTC (permalink / raw) To: linux-kernel Cc: Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds, Andrew Morton Hi, Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building the Linux kernel with gcc version 4.5 and older fails as follows. In file included from ./include/linux/mm.h:17:0, from ./include/linux/pid_namespace.h:7, from ./include/linux/ptrace.h:10, from arch/openrisc/kernel/asm-offsets.c:32: ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct This is just an example with gcc 4.5.1 for or32. I have seen the problem with gcc 4.4 (for unicore32) as well. Does that mean that gcc 4.5 and older are now officially no longer supported for compiling the kernel ? If so, would it make sense to update include/linux/compiler-gcc.h accordingly ? Thanks, Guenter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:09 Build failures with gcc 4.5 and older Guenter Roeck @ 2018-08-14 17:20 ` Linus Torvalds 2018-08-14 17:36 ` Guenter Roeck 2018-08-14 17:48 ` Joe Perches ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Linus Torvalds @ 2018-08-14 17:20 UTC (permalink / raw) To: Guenter Roeck Cc: Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > > Does that mean that gcc 4.5 and older are now officially no longer > supported for compiling the kernel ? I guess we might as well make this the excuse for making that official. Maybe it's trivially fixable, but I don't even want to look at it, since we've talked about updating the minimum gcc version so long. > If so, would it make sense to update include/linux/compiler-gcc.h > accordingly ? Unless somebody cares, and comes with a trivial fix to make old compilers happy, let's just do that. We had some other reasons to just say gcc-4.6 is the minimum version anyway. Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:20 ` Linus Torvalds @ 2018-08-14 17:36 ` Guenter Roeck 2018-08-14 20:19 ` Tony Luck 0 siblings, 1 reply; 24+ messages in thread From: Guenter Roeck @ 2018-08-14 17:36 UTC (permalink / raw) To: Linus Torvalds Cc: Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote: > On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > > > > Does that mean that gcc 4.5 and older are now officially no longer > > supported for compiling the kernel ? > > I guess we might as well make this the excuse for making that official. > > Maybe it's trivially fixable, but I don't even want to look at it, > since we've talked about updating the minimum gcc version so long. > > > If so, would it make sense to update include/linux/compiler-gcc.h > > accordingly ? > > Unless somebody cares, and comes with a trivial fix to make old > compilers happy, let's just do that. > Only implication is that it is the death warrant for unicore32, since the only compiler available for it is gcc 4.4.2. Another question is if there are still companies out there who only permit gcc 4.4 and older due to its switch to GPL3. Not that I care about any of those. Building the kernel with those old compilers without hitting some compiler bug is getting more and more difficult. Guenter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:36 ` Guenter Roeck @ 2018-08-14 20:19 ` Tony Luck 2018-08-15 16:09 ` Tony Luck 0 siblings, 1 reply; 24+ messages in thread From: Tony Luck @ 2018-08-14 20:19 UTC (permalink / raw) To: Guenter Roeck Cc: Linus Torvalds, Linux Kernel Mailing List, riel, Mike Galbraith, Dave Hansen, Andrew Morton On Tue, Aug 14, 2018 at 11:02 AM Guenter Roeck <linux@roeck-us.net> wrote: > > On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote: > > On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck <linux@roeck-us.net> wrote: > > > > > > Does that mean that gcc 4.5 and older are now officially no longer > > > supported for compiling the kernel ? > > > > I guess we might as well make this the excuse for making that official. > > > > Maybe it's trivially fixable, but I don't even want to look at it, > > since we've talked about updating the minimum gcc version so long. > > > > > If so, would it make sense to update include/linux/compiler-gcc.h > > > accordingly ? > > > > Unless somebody cares, and comes with a trivial fix to make old > > compilers happy, let's just do that. > > > > Only implication is that it is the death warrant for unicore32, > since the only compiler available for it is gcc 4.4.2. My ia64 test box only has 4.3.4. I seem to remember some pain points with newer versions of gcc on ia64. I need to poke around and find one new enough to get past this problem, but that still works for kernel building. -Tony ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 20:19 ` Tony Luck @ 2018-08-15 16:09 ` Tony Luck 2018-08-15 16:34 ` Linus Torvalds 2018-08-15 16:49 ` Guenter Roeck 0 siblings, 2 replies; 24+ messages in thread From: Tony Luck @ 2018-08-15 16:09 UTC (permalink / raw) To: Guenter Roeck Cc: Linus Torvalds, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Tue, Aug 14, 2018 at 1:19 PM Tony Luck <tony.luck@gmail.com> wrote: > My ia64 test box only has 4.3.4. I seem to remember some pain points > with newer versions of gcc on ia64. I need to poke around and find one > new enough to get past this problem, but that still works for kernel building. I had problems trying to build an up to date (or even a slightly old) gcc starting from 4.3.4. I did manage to build 4.6.4. 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK. -Tony * 958f338e96f8 ("Merge branch 'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-15 16:09 ` Tony Luck @ 2018-08-15 16:34 ` Linus Torvalds 2018-08-16 0:27 ` Guenter Roeck 2018-08-15 16:49 ` Guenter Roeck 1 sibling, 1 reply; 24+ messages in thread From: Linus Torvalds @ 2018-08-15 16:34 UTC (permalink / raw) To: Tony Luck Cc: Guenter Roeck, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Wed, Aug 15, 2018 at 9:09 AM Tony Luck <tony.luck@gmail.com> wrote: > > I did manage to build 4.6.4. > > 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK. Good. 4.6 is what we'd suggest be the new baseline, and we can hopefully keep that for a while. Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-15 16:34 ` Linus Torvalds @ 2018-08-16 0:27 ` Guenter Roeck 0 siblings, 0 replies; 24+ messages in thread From: Guenter Roeck @ 2018-08-16 0:27 UTC (permalink / raw) To: Linus Torvalds, Tony Luck Cc: Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On 08/15/2018 09:34 AM, Linus Torvalds wrote: > On Wed, Aug 15, 2018 at 9:09 AM Tony Luck <tony.luck@gmail.com> wrote: >> >> I did manage to build 4.6.4. >> >> 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK. > > Good. 4.6 is what we'd suggest be the new baseline, and we can > hopefully keep that for a while. > So, just for the record, I stopped building (or, rather, I stopped trying to build) unicore32 images for mainline and linux-next today. Guenter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-15 16:09 ` Tony Luck 2018-08-15 16:34 ` Linus Torvalds @ 2018-08-15 16:49 ` Guenter Roeck 1 sibling, 0 replies; 24+ messages in thread From: Guenter Roeck @ 2018-08-15 16:49 UTC (permalink / raw) To: Tony Luck Cc: Linus Torvalds, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Wed, Aug 15, 2018 at 09:09:17AM -0700, Tony Luck wrote: > On Tue, Aug 14, 2018 at 1:19 PM Tony Luck <tony.luck@gmail.com> wrote: > > My ia64 test box only has 4.3.4. I seem to remember some pain points > > with newer versions of gcc on ia64. I need to poke around and find one > > new enough to get past this problem, but that still works for kernel building. > > I had problems trying to build an up to date (or even a slightly old) > gcc starting from 4.3.4. > Ah yes, one of those little details: Older versions of gcc don't build anymore with recent versions of gcc. > I did manage to build 4.6.4. > > 4.6.4 built git HEAD* that failed yesterday using 4.3.4. It boots OK. > FWIW, I use gcc 8.1.0 (from kernel.org) for my ia64 test builds. Of course, I have no idea if those builds actually create bootable images. Guenter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:09 Build failures with gcc 4.5 and older Guenter Roeck 2018-08-14 17:20 ` Linus Torvalds @ 2018-08-14 17:48 ` Joe Perches 2018-08-19 21:23 ` Kees Cook 2018-08-20 17:46 ` Nick Desaulniers 2018-08-14 21:36 ` Andrew Morton 2018-08-15 12:40 ` David Laight 3 siblings, 2 replies; 24+ messages in thread From: Joe Perches @ 2018-08-14 17:48 UTC (permalink / raw) To: Guenter Roeck, linux-kernel Cc: Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds, Andrew Morton On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote: > Hi, > > Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask > (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building > the Linux kernel with gcc version 4.5 and older fails as follows. > > In file included from ./include/linux/mm.h:17:0, > from ./include/linux/pid_namespace.h:7, > from ./include/linux/ptrace.h:10, > from arch/openrisc/kernel/asm-offsets.c:32: > ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct > > This is just an example with gcc 4.5.1 for or32. I have seen the problem > with gcc 4.4 (for unicore32) as well. > > Does that mean that gcc 4.5 and older are now officially no longer > supported for compiling the kernel ? > > If so, would it make sense to update include/linux/compiler-gcc.h > accordingly ? And Documentation/process/changes.rst which shows a minimum version required of gcc as 3.2, etc... With cleaning up now unnecessary version tests in compiler-gcc.h, something like: --- Documentation/process/changes.rst | 2 +- include/linux/compiler-gcc.h | 86 ++++++++------------------------------- 2 files changed, 19 insertions(+), 69 deletions(-) diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 7a92a06f90de..61f918b10a0c 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils. ====================== =============== ======================================== Program Minimal version Command to check the version ====================== =============== ======================================== -GNU C 3.2 gcc --version +GNU C 4.6 gcc --version GNU make 3.81 make --version binutils 2.20 ld -v flex 2.5.35 flex --version diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index 573f5a7d42d4..020e4b9eee5c 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -10,6 +10,10 @@ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__) +#if GCC_VERSION < 40600 +# error Sorry, your compiler is too old - please upgrade it. +#endif + /* Optimization barrier */ /* The "volatile" is due to gcc bugs */ @@ -58,6 +62,12 @@ #define OPTIMIZER_HIDE_VAR(var) \ __asm__ ("" : "=r" (var) : "0" (var)) +/* + * A trick to suppress uninitialized variable warning without generating any + * code + */ +#define uninitialized_var(x) x = x + #ifdef __CHECKER__ #define __must_be_array(a) 0 #else @@ -91,7 +101,7 @@ * A lot of inline functions can cause havoc with function tracing. */ #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ - !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) + !defined(CONFIG_OPTIMIZE_INLINING) #define inline \ inline __attribute__((always_inline, unused)) notrace __gnu_inline #else @@ -148,47 +158,13 @@ #define __always_unused __attribute__((unused)) #define __mode(x) __attribute__((mode(x))) -/* gcc version specific checks */ - -#if GCC_VERSION < 30200 -# error Sorry, your compiler is too old - please upgrade it. -#endif - -#if GCC_VERSION < 30300 -# define __used __attribute__((__unused__)) -#else -# define __used __attribute__((__used__)) -#endif - -#ifdef CONFIG_GCOV_KERNEL -# if GCC_VERSION < 30400 -# error "GCOV profiling support for gcc versions below 3.4 not included" -# endif /* __GNUC_MINOR__ */ -#endif /* CONFIG_GCOV_KERNEL */ - -#if GCC_VERSION >= 30400 #define __must_check __attribute__((warn_unused_result)) #define __malloc __attribute__((__malloc__)) -#endif - -#if GCC_VERSION >= 40000 - -/* GCC 4.1.[01] miscompiles __weak */ -#ifdef __KERNEL__ -# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101 -# error Your version of gcc miscompiles the __weak directive -# endif -#endif #define __used __attribute__((__used__)) #define __compiler_offsetof(a, b) \ __builtin_offsetof(a, b) -#if GCC_VERSION >= 40100 -# define __compiletime_object_size(obj) __builtin_object_size(obj, 0) -#endif - -#if GCC_VERSION >= 40300 /* Mark functions as cold. gcc will assume any path leading to a call * to them will be unlikely. This means a lot of manual unlikely()s * are unnecessary now for any paths leading to the usual suspects @@ -207,24 +183,19 @@ #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) -#ifndef __CHECKER__ -# define __compiletime_warning(message) __attribute__((warning(message))) -# define __compiletime_error(message) __attribute__((error(message))) -#endif /* __CHECKER__ */ -#endif /* GCC_VERSION >= 40300 */ - -#if GCC_VERSION >= 40400 #define __optimize(level) __attribute__((__optimize__(level))) #define __nostackprotector __optimize("no-stack-protector") -#endif /* GCC_VERSION >= 40400 */ -#if GCC_VERSION >= 40500 +#define __compiletime_object_size(obj) __builtin_object_size(obj, 0) #ifndef __CHECKER__ +#define __compiletime_warning(message) __attribute__((warning(message))) +#define __compiletime_error(message) __attribute__((error(message))) + #ifdef LATENT_ENTROPY_PLUGIN #define __latent_entropy __attribute__((latent_entropy)) #endif -#endif +#endif /* __CHECKER__ */ /* * calling noreturn functions, __builtin_unreachable() and __builtin_trap() @@ -262,10 +233,6 @@ #define randomized_struct_fields_end } __randomize_layout; #endif -#endif /* GCC_VERSION >= 40500 */ - -#if GCC_VERSION >= 40600 - /* * When used with Link Time Optimization, gcc can optimize away C functions or * variables which are referenced only from assembly code. __visible tells the @@ -274,8 +241,7 @@ */ #define __visible __attribute__((externally_visible)) -#endif /* GCC_VERSION >= 40600 */ - +/* gcc version specific checks */ #if GCC_VERSION >= 40900 && !defined(__CHECKER__) /* @@ -309,10 +275,8 @@ * folding in __builtin_bswap*() (yet), so don't set these for it. */ #if defined(CONFIG_ARCH_USE_BUILTIN_BSWAP) && !defined(__CHECKER__) -#if GCC_VERSION >= 40400 #define __HAVE_BUILTIN_BSWAP32__ #define __HAVE_BUILTIN_BSWAP64__ -#endif #if GCC_VERSION >= 40800 #define __HAVE_BUILTIN_BSWAP16__ #endif @@ -341,10 +305,9 @@ * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html */ #define __designated_init __attribute__((designated_init)) +#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 #endif -#endif /* gcc version >= 40000 specific checks */ - #if !defined(__noclone) #define __noclone /* not needed */ #endif @@ -353,16 +316,6 @@ #define __no_sanitize_address #endif -/* - * A trick to suppress uninitialized variable warning without generating any - * code - */ -#define uninitialized_var(x) x = x - -#if GCC_VERSION >= 50100 -#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 -#endif - /* * Turn individual warnings and errors on and off locally, depending * on version. @@ -375,12 +328,9 @@ #define __diag_GCC_warn warning #define __diag_GCC_error error -/* Compilers before gcc-4.6 do not understand "#pragma GCC diagnostic push" */ -#if GCC_VERSION >= 40600 #define __diag_str1(s) #s #define __diag_str(s) __diag_str1(s) #define __diag(s) _Pragma(__diag_str(GCC diagnostic s)) -#endif #if GCC_VERSION >= 80000 #define __diag_GCC_8(s) __diag(s) ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:48 ` Joe Perches @ 2018-08-19 21:23 ` Kees Cook 2018-08-20 17:46 ` Nick Desaulniers 1 sibling, 0 replies; 24+ messages in thread From: Kees Cook @ 2018-08-19 21:23 UTC (permalink / raw) To: Joe Perches Cc: Guenter Roeck, LKML, Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds, Andrew Morton On Tue, Aug 14, 2018 at 10:48 AM, Joe Perches <joe@perches.com> wrote: > On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote: >> Hi, >> >> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask >> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building >> the Linux kernel with gcc version 4.5 and older fails as follows. >> >> In file included from ./include/linux/mm.h:17:0, >> from ./include/linux/pid_namespace.h:7, >> from ./include/linux/ptrace.h:10, >> from arch/openrisc/kernel/asm-offsets.c:32: >> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct >> >> This is just an example with gcc 4.5.1 for or32. I have seen the problem >> with gcc 4.4 (for unicore32) as well. >> >> Does that mean that gcc 4.5 and older are now officially no longer >> supported for compiling the kernel ? >> >> If so, would it make sense to update include/linux/compiler-gcc.h >> accordingly ? > > And Documentation/process/changes.rst which shows a > minimum version required of gcc as 3.2, etc... > > With cleaning up now unnecessary version tests in > compiler-gcc.h, something like: I rejoice at raising the minimum gcc to version 4.6! :) > --- > Documentation/process/changes.rst | 2 +- > include/linux/compiler-gcc.h | 86 ++++++++------------------------------- > 2 files changed, 19 insertions(+), 69 deletions(-) These look good, thanks: Reviewed-by: Kees Cook <keescook@chromium.org> -Kees > > diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst > index 7a92a06f90de..61f918b10a0c 100644 > --- a/Documentation/process/changes.rst > +++ b/Documentation/process/changes.rst > @@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils. > ====================== =============== ======================================== > Program Minimal version Command to check the version > ====================== =============== ======================================== > -GNU C 3.2 gcc --version > +GNU C 4.6 gcc --version > GNU make 3.81 make --version > binutils 2.20 ld -v > flex 2.5.35 flex --version > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h > index 573f5a7d42d4..020e4b9eee5c 100644 > --- a/include/linux/compiler-gcc.h > +++ b/include/linux/compiler-gcc.h > @@ -10,6 +10,10 @@ > + __GNUC_MINOR__ * 100 \ > + __GNUC_PATCHLEVEL__) > > +#if GCC_VERSION < 40600 > +# error Sorry, your compiler is too old - please upgrade it. > +#endif > + > /* Optimization barrier */ > > /* The "volatile" is due to gcc bugs */ > @@ -58,6 +62,12 @@ > #define OPTIMIZER_HIDE_VAR(var) \ > __asm__ ("" : "=r" (var) : "0" (var)) > > +/* > + * A trick to suppress uninitialized variable warning without generating any > + * code > + */ > +#define uninitialized_var(x) x = x > + > #ifdef __CHECKER__ > #define __must_be_array(a) 0 > #else > @@ -91,7 +101,7 @@ > * A lot of inline functions can cause havoc with function tracing. > */ > #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ > - !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) > + !defined(CONFIG_OPTIMIZE_INLINING) > #define inline \ > inline __attribute__((always_inline, unused)) notrace __gnu_inline > #else > @@ -148,47 +158,13 @@ > #define __always_unused __attribute__((unused)) > #define __mode(x) __attribute__((mode(x))) > > -/* gcc version specific checks */ > - > -#if GCC_VERSION < 30200 > -# error Sorry, your compiler is too old - please upgrade it. > -#endif > - > -#if GCC_VERSION < 30300 > -# define __used __attribute__((__unused__)) > -#else > -# define __used __attribute__((__used__)) > -#endif > - > -#ifdef CONFIG_GCOV_KERNEL > -# if GCC_VERSION < 30400 > -# error "GCOV profiling support for gcc versions below 3.4 not included" > -# endif /* __GNUC_MINOR__ */ > -#endif /* CONFIG_GCOV_KERNEL */ > - > -#if GCC_VERSION >= 30400 > #define __must_check __attribute__((warn_unused_result)) > #define __malloc __attribute__((__malloc__)) > -#endif > - > -#if GCC_VERSION >= 40000 > - > -/* GCC 4.1.[01] miscompiles __weak */ > -#ifdef __KERNEL__ > -# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101 > -# error Your version of gcc miscompiles the __weak directive > -# endif > -#endif > > #define __used __attribute__((__used__)) > #define __compiler_offsetof(a, b) \ > __builtin_offsetof(a, b) > > -#if GCC_VERSION >= 40100 > -# define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > -#endif > - > -#if GCC_VERSION >= 40300 > /* Mark functions as cold. gcc will assume any path leading to a call > * to them will be unlikely. This means a lot of manual unlikely()s > * are unnecessary now for any paths leading to the usual suspects > @@ -207,24 +183,19 @@ > > #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) > > -#ifndef __CHECKER__ > -# define __compiletime_warning(message) __attribute__((warning(message))) > -# define __compiletime_error(message) __attribute__((error(message))) > -#endif /* __CHECKER__ */ > -#endif /* GCC_VERSION >= 40300 */ > - > -#if GCC_VERSION >= 40400 > #define __optimize(level) __attribute__((__optimize__(level))) > #define __nostackprotector __optimize("no-stack-protector") > -#endif /* GCC_VERSION >= 40400 */ > > -#if GCC_VERSION >= 40500 > +#define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > > #ifndef __CHECKER__ > +#define __compiletime_warning(message) __attribute__((warning(message))) > +#define __compiletime_error(message) __attribute__((error(message))) > + > #ifdef LATENT_ENTROPY_PLUGIN > #define __latent_entropy __attribute__((latent_entropy)) > #endif > -#endif > +#endif /* __CHECKER__ */ > > /* > * calling noreturn functions, __builtin_unreachable() and __builtin_trap() > @@ -262,10 +233,6 @@ > #define randomized_struct_fields_end } __randomize_layout; > #endif > > -#endif /* GCC_VERSION >= 40500 */ > - > -#if GCC_VERSION >= 40600 > - > /* > * When used with Link Time Optimization, gcc can optimize away C functions or > * variables which are referenced only from assembly code. __visible tells the > @@ -274,8 +241,7 @@ > */ > #define __visible __attribute__((externally_visible)) > > -#endif /* GCC_VERSION >= 40600 */ > - > +/* gcc version specific checks */ > > #if GCC_VERSION >= 40900 && !defined(__CHECKER__) > /* > @@ -309,10 +275,8 @@ > * folding in __builtin_bswap*() (yet), so don't set these for it. > */ > #if defined(CONFIG_ARCH_USE_BUILTIN_BSWAP) && !defined(__CHECKER__) > -#if GCC_VERSION >= 40400 > #define __HAVE_BUILTIN_BSWAP32__ > #define __HAVE_BUILTIN_BSWAP64__ > -#endif > #if GCC_VERSION >= 40800 > #define __HAVE_BUILTIN_BSWAP16__ > #endif > @@ -341,10 +305,9 @@ > * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html > */ > #define __designated_init __attribute__((designated_init)) > +#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 > #endif > > -#endif /* gcc version >= 40000 specific checks */ > - > #if !defined(__noclone) > #define __noclone /* not needed */ > #endif > @@ -353,16 +316,6 @@ > #define __no_sanitize_address > #endif > > -/* > - * A trick to suppress uninitialized variable warning without generating any > - * code > - */ > -#define uninitialized_var(x) x = x > - > -#if GCC_VERSION >= 50100 > -#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 > -#endif > - > /* > * Turn individual warnings and errors on and off locally, depending > * on version. > @@ -375,12 +328,9 @@ > #define __diag_GCC_warn warning > #define __diag_GCC_error error > > -/* Compilers before gcc-4.6 do not understand "#pragma GCC diagnostic push" */ > -#if GCC_VERSION >= 40600 > #define __diag_str1(s) #s > #define __diag_str(s) __diag_str1(s) > #define __diag(s) _Pragma(__diag_str(GCC diagnostic s)) > -#endif > > #if GCC_VERSION >= 80000 > #define __diag_GCC_8(s) __diag(s) > > > -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:48 ` Joe Perches 2018-08-19 21:23 ` Kees Cook @ 2018-08-20 17:46 ` Nick Desaulniers 2018-08-20 18:34 ` Linus Torvalds 1 sibling, 1 reply; 24+ messages in thread From: Nick Desaulniers @ 2018-08-20 17:46 UTC (permalink / raw) To: joe; +Cc: akpm, dave.hansen, efault, linux-kernel, linux, riel, torvalds I think we should take Joe's patch. Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> (sorry for the lack of context, trying out the reply instructions from: https://lore.kernel.org/lkml/4cdd4ab9ddd16f1fb168266643264595782fd890.camel@perches.com/) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-20 17:46 ` Nick Desaulniers @ 2018-08-20 18:34 ` Linus Torvalds 0 siblings, 0 replies; 24+ messages in thread From: Linus Torvalds @ 2018-08-20 18:34 UTC (permalink / raw) To: Nick Desaulniers Cc: Joe Perches, Andrew Morton, Dave Hansen, Mike Galbraith, Linux Kernel Mailing List, Guenter Roeck, Rik van Riel On Mon, Aug 20, 2018 at 10:46 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > I think we should take Joe's patch. I'll happily take Joe's patch and get the whole "ancient gcc versions" issue behind us. We'll come back to it in a few years when 4.6 is ancient too, but for now we have no pressing need not to support it. Joe - proper commit message and sign-off? Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 17:09 Build failures with gcc 4.5 and older Guenter Roeck 2018-08-14 17:20 ` Linus Torvalds 2018-08-14 17:48 ` Joe Perches @ 2018-08-14 21:36 ` Andrew Morton 2018-08-14 22:15 ` Guenter Roeck 2018-08-15 12:40 ` David Laight 3 siblings, 1 reply; 24+ messages in thread From: Andrew Morton @ 2018-08-14 21:36 UTC (permalink / raw) To: Guenter Roeck Cc: linux-kernel, Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask > (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building > the Linux kernel with gcc version 4.5 and older fails as follows. > > In file included from ./include/linux/mm.h:17:0, > from ./include/linux/pid_namespace.h:7, > from ./include/linux/ptrace.h:10, > from arch/openrisc/kernel/asm-offsets.c:32: > ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct Confused. Why does it think that the mm_struct is "otherwise empty"? This shuts it up: --- a/include/linux/mm_types.h~a +++ a/include/linux/mm_types.h @@ -490,6 +490,7 @@ struct mm_struct { #endif } __randomize_layout; + int wibble; /* * The mm_cpumask needs to be at the end of mm_struct, because it * is dynamically sized based on nr_cpu_ids. So we could add something like that, along with the appropriate #if GCC_VERSION and a comment. A simple enough change, to keep those old gcc versions limping along for a bit longer? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 21:36 ` Andrew Morton @ 2018-08-14 22:15 ` Guenter Roeck 2018-08-14 23:02 ` Andrew Morton 0 siblings, 1 reply; 24+ messages in thread From: Guenter Roeck @ 2018-08-14 22:15 UTC (permalink / raw) To: Andrew Morton Cc: linux-kernel, Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds On Tue, Aug 14, 2018 at 02:36:55PM -0700, Andrew Morton wrote: > On Tue, 14 Aug 2018 10:09:04 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > > Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask > > (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building > > the Linux kernel with gcc version 4.5 and older fails as follows. > > > > In file included from ./include/linux/mm.h:17:0, > > from ./include/linux/pid_namespace.h:7, > > from ./include/linux/ptrace.h:10, > > from arch/openrisc/kernel/asm-offsets.c:32: > > ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise empty struct > Confused. Why does it think that the mm_struct is "otherwise empty"? > The problem isn't really that the structure is otherwise empty. Some digging reveals that the error message is wrong; gcc should instead complain about having no _named_ structure element before the flexible array member. > This shuts it up: > > --- a/include/linux/mm_types.h~a > +++ a/include/linux/mm_types.h > @@ -490,6 +490,7 @@ struct mm_struct { > #endif > } __randomize_layout; > > + int wibble; > /* > * The mm_cpumask needs to be at the end of mm_struct, because it > * is dynamically sized based on nr_cpu_ids. > Unfortunately, that only triggers secondary errors. Seen with both gcc 4.4 and 4.5. mm/init-mm.c:29: error: unknown field ‘mm_rb’ specified in initializer mm/init-mm.c:29: warning: missing braces around initializer mm/init-mm.c:29: warning: (near initialization for ‘init_mm.<anonymous>’) mm/init-mm.c:29: error: incompatible types when initializing type ‘struct vm_area_struct *’ using type ‘struct rb_root’ mm/init-mm.c:30: error: unknown field ‘pgd’ specified in initializer and many more similar errors. Guenter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 22:15 ` Guenter Roeck @ 2018-08-14 23:02 ` Andrew Morton 2018-08-14 23:20 ` Linus Torvalds 0 siblings, 1 reply; 24+ messages in thread From: Andrew Morton @ 2018-08-14 23:02 UTC (permalink / raw) To: Guenter Roeck Cc: linux-kernel, Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds, Thomas Gleixner On Tue, 14 Aug 2018 15:15:59 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > Confused. Why does it think that the mm_struct is "otherwise empty"? > > > > The problem isn't really that the structure is otherwise empty. > Some digging reveals that the error message is wrong; gcc should > instead complain about having no _named_ structure element before > the flexible array member. > > > This shuts it up: > > > > --- a/include/linux/mm_types.h~a > > +++ a/include/linux/mm_types.h > > @@ -490,6 +490,7 @@ struct mm_struct { > > #endif > > } __randomize_layout; > > > > + int wibble; > > /* > > * The mm_cpumask needs to be at the end of mm_struct, because it > > * is dynamically sized based on nr_cpu_ids. > > > > Unfortunately, that only triggers secondary errors. > Seen with both gcc 4.4 and 4.5. > > mm/init-mm.c:29: error: unknown field ‘mm_rb’ specified in initializer > mm/init-mm.c:29: warning: missing braces around initializer > mm/init-mm.c:29: warning: (near initialization for ‘init_mm.<anonymous>’) > mm/init-mm.c:29: error: incompatible types when initializing type ‘struct > vm_area_struct *’ using type ‘struct rb_root’ > mm/init-mm.c:30: error: unknown field ‘pgd’ specified in initializer > > and many more similar errors. This works, I think. The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT siblings at least once") was evidently never tested on CONFIG_SMP=n. How could that come about - the patch is six weeks old?? kernel/cpu.c: In function 'boot_cpu_hotplug_init': kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named 'booted_once' --- a/include/linux/mm_types.h~a +++ a/include/linux/mm_types.h @@ -490,6 +490,8 @@ struct mm_struct { #endif } __randomize_layout; + int wibble; + /* * The mm_cpumask needs to be at the end of mm_struct, because it * is dynamically sized based on nr_cpu_ids. --- a/mm/init-mm.c~a +++ a/mm/init-mm.c @@ -26,15 +26,17 @@ * and size this cpu_bitmask to NR_CPUS. */ struct mm_struct init_mm = { - .mm_rb = RB_ROOT, - .pgd = swapper_pg_dir, - .mm_users = ATOMIC_INIT(2), - .mm_count = ATOMIC_INIT(1), - .mmap_sem = __RWSEM_INITIALIZER(init_mm.mmap_sem), - .page_table_lock = __SPIN_LOCK_UNLOCKED(init_mm.page_table_lock), - .arg_lock = __SPIN_LOCK_UNLOCKED(init_mm.arg_lock), - .mmlist = LIST_HEAD_INIT(init_mm.mmlist), - .user_ns = &init_user_ns, + { + .mm_rb = RB_ROOT, + .pgd = swapper_pg_dir, + .mm_users = ATOMIC_INIT(2), + .mm_count = ATOMIC_INIT(1), + .mmap_sem = __RWSEM_INITIALIZER(init_mm.mmap_sem), + .page_table_lock = __SPIN_LOCK_UNLOCKED(init_mm.page_table_lock), + .arg_lock = __SPIN_LOCK_UNLOCKED(init_mm.arg_lock), + .mmlist = LIST_HEAD_INIT(init_mm.mmlist), + .user_ns = &init_user_ns, + }, .cpu_bitmap = { [BITS_TO_LONGS(NR_CPUS)] = 0}, INIT_MM_CONTEXT(init_mm) }; _ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 23:02 ` Andrew Morton @ 2018-08-14 23:20 ` Linus Torvalds 2018-08-15 1:02 ` Guenter Roeck 0 siblings, 1 reply; 24+ messages in thread From: Linus Torvalds @ 2018-08-14 23:20 UTC (permalink / raw) To: Andrew Morton Cc: Guenter Roeck, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Thomas Gleixner On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT > siblings at least once") was evidently never tested on CONFIG_SMP=n. > How could that come about - the patch is six weeks old?? Ehh, meet the joys of embargoes. The code was tested (and people even found subtle arm64 problems due to that testing), but because it couldn't be made public until today, it didn't go through all the usual infrastructure we depend on. But: > kernel/cpu.c: In function 'boot_cpu_hotplug_init': > kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named 'booted_once' it should be fixed now in -git. > @@ -490,6 +490,8 @@ struct mm_struct { > #endif > } __randomize_layout; > > + int wibble; > + Can we call this something informative? Like int __gcc_4_4_is_garbage_that_shouldnt_be_used; or something? That is, if we actually want to really drag out this whole pointless pain of allowing ancient compilers? Guys, at some point we need to switch to 4.6. The people who feel the pain today *will* feel the pain at some point. Just get it over with already. Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-14 23:20 ` Linus Torvalds @ 2018-08-15 1:02 ` Guenter Roeck 2018-08-20 14:53 ` Thomas Gleixner 0 siblings, 1 reply; 24+ messages in thread From: Guenter Roeck @ 2018-08-15 1:02 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Thomas Gleixner On 08/14/2018 04:20 PM, Linus Torvalds wrote: > On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <akpm@linux-foundation.org> wrote: >> >> The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT >> siblings at least once") was evidently never tested on CONFIG_SMP=n. >> How could that come about - the patch is six weeks old?? > > Ehh, meet the joys of embargoes. > > The code was tested (and people even found subtle arm64 problems due > to that testing), but because it couldn't be made public until today, > it didn't go through all the usual infrastructure we depend on. > > But: > >> kernel/cpu.c: In function 'boot_cpu_hotplug_init': >> kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named 'booted_once' > > it should be fixed now in -git. > >> @@ -490,6 +490,8 @@ struct mm_struct { >> #endif >> } __randomize_layout; >> >> + int wibble; >> + > > Can we call this something informative? Like > > int __gcc_4_4_is_garbage_that_shouldnt_be_used; > > or something? > > That is, if we actually want to really drag out this whole pointless > pain of allowing ancient compilers? > > Guys, at some point we need to switch to 4.6. The people who feel the > pain today *will* feel the pain at some point. Just get it over with > already. > For my part I am all for making gcc 4.6 mandatory. Guenter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-15 1:02 ` Guenter Roeck @ 2018-08-20 14:53 ` Thomas Gleixner 2018-08-20 16:00 ` Arnd Bergmann 0 siblings, 1 reply; 24+ messages in thread From: Thomas Gleixner @ 2018-08-20 14:53 UTC (permalink / raw) To: Guenter Roeck Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen On Tue, 14 Aug 2018, Guenter Roeck wrote: > On 08/14/2018 04:20 PM, Linus Torvalds wrote: > > On Tue, Aug 14, 2018 at 4:02 PM Andrew Morton <akpm@linux-foundation.org> > > wrote: > > > > > > The m68k build still fails because 0cc3cd21657 ("cpu/hotplug: Boot HT > > > siblings at least once") was evidently never tested on CONFIG_SMP=n. > > > How could that come about - the patch is six weeks old?? > > > > Ehh, meet the joys of embargoes. > > > > The code was tested (and people even found subtle arm64 problems due > > to that testing), but because it couldn't be made public until today, > > it didn't go through all the usual infrastructure we depend on. > > > > But: > > > > > kernel/cpu.c: In function 'boot_cpu_hotplug_init': > > > kernel/cpu.c:2275:2: error: 'struct cpuhp_cpu_state' has no member named > > > 'booted_once' > > > > it should be fixed now in -git. > > > > > @@ -490,6 +490,8 @@ struct mm_struct { > > > #endif > > > } __randomize_layout; > > > > > > + int wibble; > > > + > > > > Can we call this something informative? Like > > > > int __gcc_4_4_is_garbage_that_shouldnt_be_used; > > > > or something? > > > > That is, if we actually want to really drag out this whole pointless > > pain of allowing ancient compilers? > > > > Guys, at some point we need to switch to 4.6. The people who feel the > > pain today *will* feel the pain at some point. Just get it over with > > already. > > > > For my part I am all for making gcc 4.6 mandatory. No objections from my side. Thanks, tglx ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-20 14:53 ` Thomas Gleixner @ 2018-08-20 16:00 ` Arnd Bergmann 0 siblings, 0 replies; 24+ messages in thread From: Arnd Bergmann @ 2018-08-20 16:00 UTC (permalink / raw) To: Thomas Gleixner Cc: Guenter Roeck, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen On Mon, Aug 20, 2018 at 4:58 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > On Tue, 14 Aug 2018, Guenter Roeck wrote: > > > > For my part I am all for making gcc 4.6 mandatory. > > No objections from my side. gcc-4.6 is also what I suggested a while ago as a good choice for a new minimum version, back then I met some objection, but as time passes these probably got less important: https://lkml.org/lkml/2016/12/16/174 To recap the distros that I looked at back then using gcc older than 4.6, I found four: RHEL6: gcc-4.4 Debian 6: gcc-4.4 Ubuntu 10.04: gcc-4.4 SLES11: gcc-4.3 The first three are all finally EOL as of this month, only SLES11 with gcc-4.3 is still supported in principle: Service Pack Release FCS Date General Ends LTSS Ends SUSE Linux Enterprise Server 11 24 Mar 2009 31 Dec 2010 N/A SUSE Linux Enterprise Server 11 SP1 02 Jun 2010 31 Aug 2012 30 Aug 2015 SUSE Linux Enterprise Server 11 SP2 29 Feb 2012 31 Jan 2014 30 Jan 2017 SUSE Linux Enterprise Server 11 SP3 01 Jul 2013 31 Jan 2016 30 Jan 2019 SUSE Linux Enterprise Server 11 SP4 15 Jul 2015 31 Mar 2019 31 Mar 2022 However, installing the disro's SDK package on SLES11-SP3 brings it up to gcc-4.7, or gcc-5.2 for SP4, so this is unlikely to cause much of a problem any more. I also have some ideas for cleanups that can be done now, in particular to deal with compiler warnings. Arnd ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Build failures with gcc 4.5 and older 2018-08-14 17:09 Build failures with gcc 4.5 and older Guenter Roeck ` (2 preceding siblings ...) 2018-08-14 21:36 ` Andrew Morton @ 2018-08-15 12:40 ` David Laight 2018-08-15 15:44 ` Linus Torvalds 3 siblings, 1 reply; 24+ messages in thread From: David Laight @ 2018-08-15 12:40 UTC (permalink / raw) To: 'Guenter Roeck', linux-kernel Cc: Rik van Riel, Mike Galbraith, Dave Hansen, Linus Torvalds, Andrew Morton From: Guenter Roeck > Sent: 14 August 2018 18:09 ... > Does that mean that gcc 4.5 and older are now officially no longer > supported for compiling the kernel ? Never mind the version of gcc, the x86 kernel doesn't build with the default kernel options because the ORC unwinder hits a bug in libelf (in objtool) that was only fixed late last year. It isn't even obvious from the build log what has gone wrong. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-15 12:40 ` David Laight @ 2018-08-15 15:44 ` Linus Torvalds 2018-08-15 16:18 ` David Laight 0 siblings, 1 reply; 24+ messages in thread From: Linus Torvalds @ 2018-08-15 15:44 UTC (permalink / raw) To: David Laight Cc: Guenter Roeck, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Wed, Aug 15, 2018 at 5:38 AM David Laight <David.Laight@aculab.com> wrote: > > Never mind the version of gcc, the x86 kernel doesn't build with the > default kernel options because the ORC unwinder hits a bug in libelf > (in objtool) that was only fixed late last year. > > It isn't even obvious from the build log what has gone wrong. Can you give more details? We should try to work around it. It's one thing to care about a compiler that is almost a decade old. At some point we just have to let it go. But some libelf bug that is less than a year old is likely to bite people. Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Build failures with gcc 4.5 and older 2018-08-15 15:44 ` Linus Torvalds @ 2018-08-15 16:18 ` David Laight 2018-08-15 16:33 ` Linus Torvalds 0 siblings, 1 reply; 24+ messages in thread From: David Laight @ 2018-08-15 16:18 UTC (permalink / raw) To: 'Linus Torvalds' Cc: Guenter Roeck, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton From: Linus Torvalds > Sent: 15 August 2018 16:44 > On Wed, Aug 15, 2018 at 5:38 AM David Laight <David.Laight@aculab.com> wrote: > > > > Never mind the version of gcc, the x86 kernel doesn't build with the > > default kernel options because the ORC unwinder hits a bug in libelf > > (in objtool) that was only fixed late last year. > > > > It isn't even obvious from the build log what has gone wrong. > > Can you give more details? We should try to work around it. > > It's one thing to care about a compiler that is almost a decade old. > At some point we just have to let it go. > > But some libelf bug that is less than a year old is likely to bite people. See https://lkml.org/lkml/2017/9/10/186 for the libelf fix. It isn't anything like as rare as those emails suggest. An 'allmodconfig' build fails on a lot of object files after 4.15-rc9. When I fell over the problem I found a few reports on the ubuntu lists but they all just said the ubuntu version was unsupported. There is this patch I did https://lkml.org/lkml/2018/7/26/266 that got no comments. But really something needs to be done to objtool. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Build failures with gcc 4.5 and older 2018-08-15 16:18 ` David Laight @ 2018-08-15 16:33 ` Linus Torvalds 2018-08-16 9:17 ` David Laight 0 siblings, 1 reply; 24+ messages in thread From: Linus Torvalds @ 2018-08-15 16:33 UTC (permalink / raw) To: David Laight Cc: Guenter Roeck, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton On Wed, Aug 15, 2018 at 9:16 AM David Laight <David.Laight@aculab.com> wrote: > > > > > But some libelf bug that is less than a year old is likely to bite people. > > See https://lkml.org/lkml/2017/9/10/186 for the libelf fix. > It isn't anything like as rare as those emails suggest. > An 'allmodconfig' build fails on a lot of object files after 4.15-rc9. Ok, but that patch that fixes it was merged a long time ago already. See commit 97dab2ae7e84 ("objtool: Fix object file corruption") So I'm a bit confused by your issue. The thing you point to from last year was literall fixed and committed to the tree in a couple of days days. > When I fell over the problem I found a few reports on the ubuntu lists > but they all just said the ubuntu version was unsupported. > > There is this patch I did https://lkml.org/lkml/2018/7/26/266 that got > no comments. > > But really something needs to be done to objtool. I think you need to make a report about the exact problem with objtool and your issue. Not on the ubuntu lists, but to Josh. Linus ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Build failures with gcc 4.5 and older 2018-08-15 16:33 ` Linus Torvalds @ 2018-08-16 9:17 ` David Laight 0 siblings, 0 replies; 24+ messages in thread From: David Laight @ 2018-08-16 9:17 UTC (permalink / raw) To: 'Linus Torvalds' Cc: Guenter Roeck, Linux Kernel Mailing List, Rik van Riel, Mike Galbraith, Dave Hansen, Andrew Morton From: Linus Torvalds > Sent: 15 August 2018 17:34 > To: David Laight > Cc: Guenter Roeck; Linux Kernel Mailing List; Rik van Riel; Mike Galbraith; Dave Hansen; Andrew Morton > Subject: Re: Build failures with gcc 4.5 and older > > On Wed, Aug 15, 2018 at 9:16 AM David Laight <David.Laight@aculab.com> wrote: > > > > > > > > But some libelf bug that is less than a year old is likely to bite people. > > > > See https://lkml.org/lkml/2017/9/10/186 for the libelf fix. > > It isn't anything like as rare as those emails suggest. > > An 'allmodconfig' build fails on a lot of object files after 4.15-rc9. > > Ok, but that patch that fixes it was merged a long time ago already. > See commit 97dab2ae7e84 ("objtool: Fix object file corruption") > > So I'm a bit confused by your issue. The thing you point to from last > year was literall fixed and committed to the tree in a couple of days > days. Hmmm... I still had to update from libelf-0.153.so to libelf-0.165.so in order to get the output from objtool to be valid. I'm sure I'd seen a patch to libelf as well. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2018-08-20 18:34 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-14 17:09 Build failures with gcc 4.5 and older Guenter Roeck 2018-08-14 17:20 ` Linus Torvalds 2018-08-14 17:36 ` Guenter Roeck 2018-08-14 20:19 ` Tony Luck 2018-08-15 16:09 ` Tony Luck 2018-08-15 16:34 ` Linus Torvalds 2018-08-16 0:27 ` Guenter Roeck 2018-08-15 16:49 ` Guenter Roeck 2018-08-14 17:48 ` Joe Perches 2018-08-19 21:23 ` Kees Cook 2018-08-20 17:46 ` Nick Desaulniers 2018-08-20 18:34 ` Linus Torvalds 2018-08-14 21:36 ` Andrew Morton 2018-08-14 22:15 ` Guenter Roeck 2018-08-14 23:02 ` Andrew Morton 2018-08-14 23:20 ` Linus Torvalds 2018-08-15 1:02 ` Guenter Roeck 2018-08-20 14:53 ` Thomas Gleixner 2018-08-20 16:00 ` Arnd Bergmann 2018-08-15 12:40 ` David Laight 2018-08-15 15:44 ` Linus Torvalds 2018-08-15 16:18 ` David Laight 2018-08-15 16:33 ` Linus Torvalds 2018-08-16 9:17 ` David Laight
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).