[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150408153112.bd375a883138f4c9fd319645@linux-foundation.org>
Date: Wed, 8 Apr 2015 15:31:12 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Andi Kleen <andi@...stfloor.org>
Cc: mmarek@...e.cz, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] lto: Add __noreorder and mark initcalls __noreorder
On Wed, 8 Apr 2015 06:17:38 -0700 Andi Kleen <andi@...stfloor.org> wrote:
> From: Andi Kleen <ak@...ux.intel.com>
>
> gcc 5 has a new no_reorder attribute that prevents top level
> reordering only for that symbol.
I'm having trouble locating gcc documentation which explains all this
stuff.
> Kernels don't like any reordering of initcalls between files, as several
> initcalls depend on each other. LTO previously needed to use
> -fno-toplevel-reordering to prevent boot failures.
That's "-fno-toplevel-reorder", I believe?
> Add a __noreorder wrapper for the no_reorder attribute and use
> it for initcalls.
Head is spinning a bit. As this all appears to be shiny new
added-by-andi gcc functionality, it would be useful if we could have a
few more words describing what it's all about. Reordering of what with
respect to what and why and why is it bad. Why is gcc reordering
things anyway, and what's the downside of preventing this. Why is the
compiler reordering things rather than the linker. etc etc etc.
Please gently educate us ;)
--
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/
Powered by blists - more mailing lists