Re: section breakage on ppc64 (aka __devinitconst is broken by design)

["Jan Beulich" <jbeulich@novell.com>]

>Al posted the following:
>====================================================================
>; cat >a.c <<'EOF'
>const char foo[] __attribute__ ((__section__(".blah"))) = "";
>const char * const bar __attribute__((__section__(".blah"))) = "";
>EOF
>; gcc -m32 -S a.c
>; gcc -m64 -S a.c
>a.c:2: error: bar causes a section type conflict
>;
>
>That's 4.1.2 on ppc.  What happens is that the second declaration
>wants to make .blah writable.  We actually trigger that in ppc64
>builds on drivers/net/natsemi.c.
>
>Note that on ppc64 without explicit sections you have the second one land in
>.data.rel.ro.local, which is "aw",progbits.
>====================================================================
>
>Se we see that despite being marked as const the the section
>is in one case marked as read-only by gcc and in another case the section
>is marked as rw.

Oh, indeed, this kind of a construct also fails for ia64 on existing gcc-s.

>And this is with the gcc version that is in use today and which
>we must support.
>Thats why I think we have to loose the constification that is going on
>or we should loose the section attribute on the data.

That is very unfortunate, but is then a good reason to fold the
'const' into the __devinitconst definition as I originally suggested (and
perhaps that's the reason why I didn't have problems with my version
of the patch on ia64) - that way, those architectures that can't tolerate
it could have __devinitconst continue to resolve to __devinitdata,
resulting in traditional section allocation, while targets like x86 can still
benefit from the constification.

Apart from that we may want to approach the gcc folks to allow a way
to override this 'optimization for the kernel (or more generally for
statically linked executables).

Jan