lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists