From: Al Viro <viro@ZenIV.linux.org.uk>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: section breakage on ppc64 (aka __devinitconst is broken by design)
Date: Sun, 3 Feb 2008 21:02:08 +0000 [thread overview]
Message-ID: <20080203210208.GU27894@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20080203203002.GD2648@uranus.ravnborg.org>
On Sun, Feb 03, 2008 at 09:30:02PM +0100, Sam Ravnborg wrote:
> And I'm suprised to see that gcc thinks bar is writeable.
> If I try to assign it gcc error out as expected.
That's because "not modifiable" and "goes into r/o section" are not the
same thing. The former belongs to C and is target-independent, of course.
The latter is up to implementation, except that modifiable objects
obviously *can not* go into r/o. You are not guaranteed the reverse.
> We could invent a __initstr annotation but I dunno if that would suffice.
> Do you see any pattern when gcc do the r/w choice compared to the
> r/o choise. Maybe it is only const char[] that happens to be considered
> r/o and the rest is r/w?
On ppc64 relocs => r/w, AFAICS. On other targets we might have any number
of other rules.
> Should a gcc-bug be filed for this btw?
Why? gcc is entirely within its rights - it's not even a matter of ABI,
it's way below that. Note that you are meddling with section assignment
rules and those are target-dependent, so target-independent overrides
are nowhere near being promised to work.
Frankly, "do not ever make __initdata et.al. const" is probably the best
we can do - adding __initconst, __initconst_but_has_relocs,
__initconst_but_has_something_that_puts_it_into_writable_on_this_weird_target,
__initconst_but_has_something_that_puts_it_into_writable_on_that_weird_target,
etc. is not feasible - we'll keep getting portability bugs all the time since
nobody will remember all rules (or care about ones that do not apply on
amd64).
Suppose we have an array of ad-hoc structs with a bunch of ints
in those. Used only in ->probe(), so __devinitdata. Constant, so
__devinitconst (and no special per-target rules trigger on the current
struct contents). Fast forward half a year; somebody adds a string field
to those. Oops - suddenly it's __devinitconst_but_has_relocs, but author
of that patch has never heard of ppc64 oddities; on all targets he knows
__devinitconst still works fine.
next prev parent reply other threads:[~2008-02-03 21:02 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 [this message]
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=20080203210208.GU27894@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.