From: Sam Ravnborg <sam@ravnborg.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: section breakage on ppc64 (aka __devinitconst is broken by design)
Date: Sun, 3 Feb 2008 18:26:35 +0100 [thread overview]
Message-ID: <20080203172635.GA2275@uranus.ravnborg.org> (raw)
In-Reply-To: <20080203130844.GS27894@ZenIV.linux.org.uk>
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.
We recently had breakage in mainline with x86 64 bit
(sis190) for the exact same case.
Does this work in your ppc example or do we need
to find another solution?
Sam
next prev parent reply other threads:[~2008-02-03 17:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 13:08 section breakage on ppc64 (aka __devinitconst is broken by design) Al Viro
2008-02-03 17:26 ` Sam Ravnborg [this message]
2008-02-03 18:02 ` Al Viro
2008-02-03 20:30 ` Sam Ravnborg
2008-02-03 21:02 ` Al Viro
2008-02-04 0:27 ` Olivier Galibert
2008-02-07 18:33 ` Chuck Ebbert
2008-02-07 18:54 ` Sam Ravnborg
2008-02-08 8:14 ` Jan Beulich
2008-02-08 8:47 ` Sam Ravnborg
2008-02-08 9:17 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080203172635.GA2275@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox