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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
