lkml.org 
[lkml]   [2008]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: section breakage on ppc64 (aka __devinitconst is broken by design)
    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).


    \
     
     \ /
      Last update: 2008-02-03 19:05    [W:0.026 / U:62.748 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site