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: Fri, 22 Feb 2008 10:38:00 +0800 From: "Huang, Ying" <ying.huang@...el.com> To: Ingo Molnar <mingo@...e.hu> Cc: Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, Andi Kleen <ak@...e.de>, Ian Campbell <ijc@...lion.org.uk>, Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 2/2] x86 : relocate uninitialized variable in init DATA section into init BSS section On Thu, 2008-02-21 at 10:53 +0100, Ingo Molnar wrote: > * Huang, Ying <ying.huang@...el.com> wrote: > > > > > -int __initdata early_ioremap_debug; > > > > +int __initbss early_ioremap_debug; > > > > > > will we get some sort of build error if we accidentally do: > > > > > > int __initbss early_ioremap_debug = 1; > > > > > > ? > > > > I tested it just now, and there is no build error. > > well, that's bad. We'd silently ignore the " = 1" and boot up with that > value at 0, right? At minimum we need some really prominent build-time > _errors_ (i.e. aborted builds) if this ever happens. But ideally, > shouldnt this whole thing be done at link time? Couldnt the linker sort > the variables that are zero initialized into the right section, and move > this constant maintenance pressure off the programmer's shoulder? I think another method is to add a new attribute into GCC to prepend or append something to section name instead of just to replace it, like the example as follow: #define __initdata __attribute__((section_append(".init"))) int __initdata early_ioremap_debug_data = 1; int __initdata early_ioremap_debug_bss; The GCC can deduce the section (.data or .bss) of global variable based on whether it is initialized. That is, without attribute, early_ioremap_debug_data will be in ".data", early_ioremap_debug_bss will be in ".bss". And with section_append attribute, early_ioremap_debug_data will be in ".data.init" and early_ioremap_debug_bss will be in ".bss.init". Best Regards, Huang Ying -- 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