[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0708160338520.22701@enigma.security.iitk.ac.in>
Date: Thu, 16 Aug 2007 06:06:00 +0530 (IST)
From: Satyam Sharma <satyam@...radead.org>
To: Segher Boessenkool <segher@...nel.crashing.org>
cc: horms@...ge.net.au, Stefan Richter <stefanr@...6.in-berlin.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, ak@...e.de,
netdev@...r.kernel.org, cfriesen@...tel.com,
Heiko Carstens <heiko.carstens@...ibm.com>,
rpjday@...dspring.com, jesper.juhl@...il.com,
linux-arch@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, zlynx@....org,
clameter@....com, schwidefsky@...ibm.com,
Chris Snook <csnook@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>, davem@...emloft.net,
Linus Torvalds <torvalds@...ux-foundation.org>,
wensong@...ux-vs.org, wjiang@...ilience.com
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again. Isn't "any code
> > that it cannot currently see" the same as "another compilation unit",
>
> It is not; try gcc -combine or the upcoming link-time optimisation
> stuff, for example.
>
> > and wouldn't the "compilation unit" itself expand if we ask gcc to
> > compile more than one unit at once? Or is there some more specific
> > "definition" for "compilation unit" (in gcc lingo, possibly?)
>
> "compilation unit" is a C standard term. It typically boils down
> to "single .c file".
As you mentioned later, "single .c file with all the other files (headers
or other .c files) that it pulls in via #include" is actually "translation
unit", both in the C standard as well as gcc docs. "Compilation unit"
doesn't seem to be nearly as standard a term, though in most places it
is indeed meant to be same as "translation unit", but with the new gcc
inter-module-analysis stuff that you referred to above, I suspect one may
reasonably want to call a "compilation unit" as all that the compiler sees
at a given instant.
BTW I did some auditing (only inside include/asm-{i386,x86_64}/ and
arch/{i386,x86_64}/) and found a couple more callsites that don't use
cpu_relax():
arch/i386/kernel/crash.c:101
arch/x86_64/kernel/crash.c:97
that are:
while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
mdelay(1);
msecs--;
}
where mdelay() becomes __const_udelay() which happens to be in another
translation unit (arch/i386/lib/delay.c) and hence saves this callsite
from being a bug :-)
Curiously, __const_udelay() is still marked as "inline" where it is
implemented in lib/delay.c which is weird, considering it won't ever
be inlined, would it? With the kernel presently being compiled one
translation unit at a time, I don't see how the implementation would
be visible to any callsite out there to be able to inline it.
Satyam
-
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