All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: kernel test robot <lkp@intel.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, lkp@lists.01.org, keescook@chromium.org,
	hjl.tools@gmail.com, linux@rasmusvillemoes.dk,
	linux-toolchains@vger.kernel.org
Subject: GCC section alignment, and GCC-4.9 being a weird one
Date: Wed, 21 Oct 2020 10:00:31 +0200	[thread overview]
Message-ID: <20201021080031.GY2628@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <58ff47cc-dc55-e383-7a5b-37008d145aba@gmail.com>

On Tue, Oct 20, 2020 at 04:39:38PM -0700, Florian Fainelli wrote:
> This patch causes all files under kernel/sched/* that include sched.h to
> be rebuilt whenever the value of CONFIG_BLK_DEV_INITRD. There are at
> least two build systems (buildroot and OpenWrt) that toggle this
> configuration value in order to produce a kernel image without an
> initramfs, and one with.
> 
> On ARM we get all of these to be needlessly rebuilt:

Is it really ARM specific? AFAICT this should happen on everything.

> Short of moving the STRUCT_ALIGNMENT to a separate header that would not
> be subject to any configuration key change, can you think of a good way
> to avoid these rebuilds, including for architectures like ARM that ship
> their own vmlinux.lds.h? I would not say this is a bug, but it is
> definitively an inconvenience.

Well, no :/ I barely made it work in the first place. This linker cruft
is not my forte. GCC-4.9 being 'special' here is just weird in any case.

We can ask our friends on linux-toolchains; maybe they'll have a clue.

Guys, the problem is the below commit which, for dubious raisins makes
kernel/sched/sched.h depend on asm-generic/vmlinux.lds.h and triggers
rebuilds whenever a CONFIG mentioned in asm-generic/vmlinux.lds.h
changes.

Is there an explanation for why GCC-4.9 is weird and is there a better
way to find the appropriate value?


---
commit 85c2ce9104eb93517db2037699471c517e81f9b4
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jun 30 16:49:05 2020 +0200

    sched, vmlinux.lds: Increase STRUCT_ALIGNMENT to 64 bytes for GCC-4.9
    
    For some mysterious reason GCC-4.9 has a 64 byte section alignment for
    structures, all other GCC versions (and Clang) tested (including 4.8
    and 5.0) are fine with the 32 bytes alignment.
    
    Getting this right is important for the new SCHED_DATA macro that
    creates an explicitly ordered array of 'struct sched_class' in the
    linker script and expect pointer arithmetic to work.
    
    Fixes: c3a340f7e7ea ("sched: Have sched_class_highest define by vmlinux.lds.h")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20200630144905.GX4817@hirez.programming.kicks-ass.net

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 66fb84c3dc7e..3ceb4b7279ec 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -108,6 +108,17 @@
 #define SBSS_MAIN .sbss
 #endif
 
+/*
+ * GCC 4.5 and later have a 32 bytes section alignment for structures.
+ * Except GCC 4.9, that feels the need to align on 64 bytes.
+ */
+#if __GNUC__ == 4 && __GNUC_MINOR__ == 9
+#define STRUCT_ALIGNMENT 64
+#else
+#define STRUCT_ALIGNMENT 32
+#endif
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
+
 /*
  * The order of the sched class addresses are important, as they are
  * used to determine the order of the priority of each sched class in
@@ -123,13 +134,6 @@
 	*(__stop_sched_class)			\
 	__end_sched_classes = .;
 
-/*
- * Align to a 32 byte boundary equal to the
- * alignment gcc 4.5 uses for a struct
- */
-#define STRUCT_ALIGNMENT 32
-#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
-
 /* The actual configuration determine if the init/exit sections
  * are handled as text/data or they can be discarded (which
  * often happens at runtime)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 5aa6661ecaf1..9bef2dd01247 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -67,6 +67,7 @@
 #include <linux/tsacct_kern.h>
 
 #include <asm/tlb.h>
+#include <asm-generic/vmlinux.lds.h>
 
 #ifdef CONFIG_PARAVIRT
 # include <asm/paravirt.h>
@@ -1810,7 +1811,7 @@ struct sched_class {
 #ifdef CONFIG_FAIR_GROUP_SCHED
 	void (*task_change_group)(struct task_struct *p, int type);
 #endif
-} __aligned(32); /* STRUCT_ALIGN(), vmlinux.lds.h */
+} __aligned(STRUCT_ALIGNMENT); /* STRUCT_ALIGN(), vmlinux.lds.h */
 
 static inline void put_prev_task(struct rq *rq, struct task_struct *prev)
 {



  reply	other threads:[~2020-10-21  8:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29  0:31 [sched] c3a340f7e7: invalid_opcode:#[##] kernel test robot
2020-06-29  0:31 ` kernel test robot
2020-06-30 12:46 ` Peter Zijlstra
2020-06-30 12:46   ` Peter Zijlstra
2020-06-30 13:55   ` Rasmus Villemoes
2020-06-30 13:55     ` Rasmus Villemoes
2020-06-30 14:02     ` Peter Zijlstra
2020-06-30 14:02       ` Peter Zijlstra
2020-06-30 14:11       ` Peter Zijlstra
2020-06-30 14:11         ` Peter Zijlstra
2020-06-30 14:35       ` Peter Zijlstra
2020-06-30 14:35         ` Peter Zijlstra
2020-06-30 14:49   ` Peter Zijlstra
2020-06-30 14:49     ` Peter Zijlstra
2020-07-09  8:45     ` [tip: sched/core] sched, vmlinux.lds: Increase STRUCT_ALIGNMENT to 64 bytes for GCC-4.9 tip-bot2 for Peter Zijlstra
2020-10-20 23:39     ` [sched] c3a340f7e7: invalid_opcode:#[##] Florian Fainelli
2020-10-21  8:00       ` Peter Zijlstra [this message]
2020-10-21 13:18         ` GCC section alignment, and GCC-4.9 being a weird one Jakub Jelinek
2020-10-21 13:44           ` Peter Zijlstra
2020-10-21 17:42             ` Nick Desaulniers
2020-10-21 17:54               ` Miguel Ojeda
2020-10-21 18:35                 ` Joe Perches
2020-10-21 18:35                   ` [Linux-kernel-mentees] " Joe Perches
2020-10-21 19:27                   ` Miguel Ojeda
2020-10-21 19:27                     ` [Linux-kernel-mentees] " Miguel Ojeda
2020-10-22  7:38               ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201021080031.GY2628@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=f.fainelli@gmail.com \
    --cc=hjl.tools@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=rostedt@goodmis.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.