>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 -- 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/