From: "Jan Beulich" <jbeulich@novell.com>
To: "Sam Ravnborg" <sam@ravnborg.org>, "Chuck Ebbert" <cebbert@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, "Al Viro" <viro@ZenIV.linux.org.uk>
Subject: Re: section breakage on ppc64 (aka __devinitconst is broken by design)
Date: Fri, 08 Feb 2008 08:14:11 +0000 [thread overview]
Message-ID: <47AC1D63.76E4.0078.0@novell.com> (raw)
In-Reply-To: <20080207185409.GA21145@uranus.ravnborg.org>
>I cannot see any other way out of this than to loose all the newly added
>consts. We have to different behavior across platforms to find a suitable
>solution that is reliable.
>
>[Kept rest of mail as I added Jan - hope he have some ideas to throw in].
I'd first of all need a better understanding of what these comments are
really based upon:
/* On some platforms relocations to global data cannot go into read-only
sections, so 'const' makes no sense and even causes compile failures
with some compilers. */
While I can see such behavior as reasonable for, say, shared objects,
I severely doubt that this is generally appropriate for executables, not
to say for the kernel. This is particularly in the light of this comment in
gcc/output.h:
/* To optimize loading of shared programs, define following subsections
of data section:
which clearly says that the resulting (default) object placement (of read-
only data in writeable sections) is an optimization, not a requirement,
and even then only for shared programs (which the kernel clearly isn't).
Has there been any communication with the gcc folks on this subject?
Jan
next prev parent reply other threads:[~2008-02-08 8:14 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
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 [this message]
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=47AC1D63.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=cebbert@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.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