[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1375723451.22073.85.camel@gandalf.local.home>
Date: Mon, 05 Aug 2013 13:24:11 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "H. Peter Anvin" <hpa@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>, gcc <gcc@....gnu.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Thomas Gleixner <tglx@...utronix.de>,
David Daney <ddaney.cavm@...il.com>,
Behan Webster <behanw@...verseincode.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC] gcc feature request: Moving blocks into sections
On Mon, 2013-08-05 at 10:02 -0700, H. Peter Anvin wrote:
> > if (x) __attibute__((section(".foo"))) {
> > /* do something */
> > }
> >
>
> One concern I have is how this kind of code would work when embedded
> inside a function which already has a section attribute. This could
> easily cause really weird bugs when someone "optimizes" an inline or
> macro and breaks a single call site...
I would say that it overrides the section it is embedded in. Basically
like a .pushsection and .popsection would work.
What bugs do you think would happen? Sure, this used in an .init section
would have this code sit around after boot up. I'm sure modules could
handle this properly. What other uses of attribute section is there for
code? I'm aware of locks and sched using it but that's more for
debugging purposes and even there, the worse thing I see is that a debug
report wont say that the code is in the section.
We do a lot of tricks with sections in the Linux kernel, so I too share
your concern. But even with that, if we audit all use cases, we may
still be able to safely do this. This is why I'm asking for comments :-)
-- Steve
--
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