On Sun, Dec 04, 2005 at 05:41:43PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
> To: Jean Delvare <[email protected]>
> Subject: Re: Questions on __initdata
> Date: Sun, 4 Dec 2005 17:41:43 +0100
> Cc: LKML <[email protected]>
> Content-Type: text/plain; charset=iso-8859-1
>
> Am Sonntag 04 Dezember 2005 15:15 schrieb Jean Delvare:
>
> > My tests (on i386) seem to suggest that "doesn't apply to uninitialized
> > data" only holds for non-global variables. Tagging uninitialized global
> > variables __initdata works, and moves the variables from .bss to .data.
> > Is it correct? Does it work on all archs? If so, the comment above
> > needs to be fixed.
>
> Yes, your observation is correct. Note that newer gcc versions treat
> data that is initialized to zero the same way as uninitialized data (by
> putting it into .bss), but that should be independent of the architecture.
>
> > I'm also slightly puzzled by the whole concept of __initdata static
> > local variables. They only seem to make sense if the function itself is
> > tagged __init. If so, isn't it redundant to tag the data __initdata?
>
> No. If the function is tagged __init, it goes into the init section, but
> static variable in it still go to .bss, so you have to flag them separately.
> It would be nice if gcc could determine that automatically, but the
> current __attribute__((section())) syntax does not allow that.
>
> > As a side question, given that an uninitialized global variable being
> > tagged __initdata will be moved from .bss to .data, will it become a
> > truly uninitialized variable? Or will it automatically be initialized
> > to 0 by the compiler as .bss is?
>
> .bss is special in that it is not initialized by the compiler but by the
> ELF loader, or case of the kernel, some very early kernel code.
> Moving data from .bss to __initdata causes it to be initialized to
> zero by the compiler and it becomes part of the object file.
>
> > + *
> > + * Uninitialized static local variables cannot be made "__initdata".
> > *
> As explained above, this sentence is wrong.
>
> > *
> > * Also note, that this data cannot be "const".
>
> I think this sentence is wrong as well, can anyone clarify why you should
> not be able to have const __initdata?
gcc hates it:
static const int __initdata somevariable = 42;
will result in something like:
blurb.c: At top level:
blurb.c:3: error: somevariable causes a section type conflict
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]