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

[Al Viro]

On Sun, Feb 03, 2008 at 06:26:35PM +0100, Sam Ravnborg wrote:
> On Sun, Feb 03, 2008 at 01:08:44PM +0000, Al Viro wrote:
> > ; 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.
> > 
> > The reason why it didn't visibly bite us before is that usually __devinit...
> > just expanded to nothing (unless you disable HOTPLUG, which requires
> > EMBEDDED, which wasn't apparently common enough for ppc64 builds).
> > 
> > Suggestions?
> 
> Hi Al.
> 
> __devinitconst were invented to cover this issue.
> So use __devinitconst for const data and 
> __devinitdata for non-const data.

As the example above shows, what is and what is not const data is
irrelevant.  The data _is_ const.  On ppc32 gcc is happy to put
it into read-only section.  On ppc64 the same version of gcc insists
on making the section this data object is going to *writable*.

> We recently had breakage in mainline with x86 64 bit
> (sis190) for the exact same case.

No, this is not exact same case.  Unfortunately.

> Does this work in your ppc example or do we need
> to find another solution?

Please, read the posted example.  s/.blah/.devinit.rodata/ if you wish - it's
not magical.  What happens is that
	* gcc choice of r/o vs. r/w section is not determined by object
being const
	* that choice is actually platform-dependent, even between related
platforms (see ppc32 and ppc64 in the example above).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/