| Message ID | 1376687156-6737-3-git-send-email-julien.grall@linaro.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
>>> Julien Grall <julien.grall@linaro.org> 08/16/13 11:06 PM >>> >It's possible to have 2 type (const and non-const) of data in the same >compilation unit. Using only __initdata will result to a compilation error: > >error: $variablename causes as section tupe conflict with $variablename2 > >because a section containing const variables is marked read only and so cannot >contain non-const variables. I don't mind this change, but so far we avoided this by simply not marking such objects 'const'. I didn't check whether the ARM port is different in this regard, but the x86 port till now didn't care to mark regular read-only data read-only at runtime, so there's little point in being over-ambitious for init- only data. Jan
On Mon, 2013-08-19 at 10:46 +0100, Jan Beulich wrote: > >>> Julien Grall <julien.grall@linaro.org> 08/16/13 11:06 PM >>> > >It's possible to have 2 type (const and non-const) of data in the same > >compilation unit. Using only __initdata will result to a compilation error: > > > >error: $variablename causes as section tupe conflict with $variablename2 > > > >because a section containing const variables is marked read only and so cannot > >contain non-const variables. > > I don't mind this change, but so far we avoided this by simply not marking > such objects 'const'. I didn't check whether the ARM port is different in this > regard, but the x86 port till now didn't care to mark regular read-only data > read-only at runtime, so there's little point in being over-ambitious for init- > only data. ARM has some reasonable amount of initdata to describe the device tree platform drivers etc. It seems reasonable to make those const to me. (I'm a bit surprised at the gcc behaviour of not allowing const and non const data in the same section, but whatever) Ian.
>>> On 19.08.13 at 16:56, Ian Campbell <Ian.Campbell@citrix.com> wrote: > (I'm a bit surprised at the gcc behaviour of not allowing const and non > const data in the same section, but whatever) Iirc that got fixed in newer gcc versions, but we continue to support (on x86 at least) ones that dislike mixing section attributes. Jan
On Tue, 2013-08-20 at 08:12 +0100, Jan Beulich wrote: > >>> On 19.08.13 at 16:56, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > (I'm a bit surprised at the gcc behaviour of not allowing const and non > > const data in the same section, but whatever) > > Iirc that got fixed in newer gcc versions, but we continue to support > (on x86 at least) ones that dislike mixing section attributes. Since Julien is running on ARM, I think with linaro cross-compilers, he is quite likely running gcc 4.7 or 4.8, which are pretty new I think. Ian.
>>> On 20.08.13 at 10:31, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2013-08-20 at 08:12 +0100, Jan Beulich wrote: >> >>> On 19.08.13 at 16:56, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > (I'm a bit surprised at the gcc behaviour of not allowing const and non >> > const data in the same section, but whatever) >> >> Iirc that got fixed in newer gcc versions, but we continue to support >> (on x86 at least) ones that dislike mixing section attributes. > > Since Julien is running on ARM, I think with linaro cross-compilers, he > is quite likely running gcc 4.7 or 4.8, which are pretty new I think. I was just suspecting that a build problem may have been found by him when build-checking x86... Jan
On 20 August 2013 09:31, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2013-08-20 at 08:12 +0100, Jan Beulich wrote: >> >>> On 19.08.13 at 16:56, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > (I'm a bit surprised at the gcc behaviour of not allowing const and non >> > const data in the same section, but whatever) >> >> Iirc that got fixed in newer gcc versions, but we continue to support >> (on x86 at least) ones that dislike mixing section attributes. > > Since Julien is running on ARM, I think with linaro cross-compilers, he > is quite likely running gcc 4.7 or 4.8, which are pretty new I think. I use gcc 4.8 42sh> gcc --version arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.04-20130417 - Linaro GCC 2013.04) 4.8.1 20130401 (prerelease)
On Fri, 2013-08-16 at 22:05 +0100, Julien Grall wrote: > It's possible to have 2 type (const and non-const) of data in the same > compilation unit. Using only __initdata will result to a compilation error: > > error: $variablename causes as section tupe conflict with $variablename2 > > because a section containing const variables is marked read only and so cannot > contain non-const variables. > > Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com> But that is not in itself sufficient, please remember to CC the right maintainers, especially for non-ARM specific patches. That probably means Jan and Keir here (I cc'd both, even though Jan has obviously already seen and commented) > --- > xen/include/xen/init.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h > index b602577..9d481b3 100644 > --- a/xen/include/xen/init.h > +++ b/xen/include/xen/init.h > @@ -10,6 +10,7 @@ > #define __init __text_section(".init.text") > #define __exit __text_section(".exit.text") > #define __initdata __section(".init.data") > +#define __initconst __section(".init.rodata") > #define __exitdata __used_section(".exit.data") > #define __initsetup __used_section(".init.setup") > #define __init_call(lvl) __used_section(".initcall" lvl ".init")
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h index b602577..9d481b3 100644 --- a/xen/include/xen/init.h +++ b/xen/include/xen/init.h @@ -10,6 +10,7 @@ #define __init __text_section(".init.text") #define __exit __text_section(".exit.text") #define __initdata __section(".init.data") +#define __initconst __section(".init.rodata") #define __exitdata __used_section(".exit.data") #define __initsetup __used_section(".init.setup") #define __init_call(lvl) __used_section(".initcall" lvl ".init")
It's possible to have 2 type (const and non-const) of data in the same compilation unit. Using only __initdata will result to a compilation error: error: $variablename causes as section tupe conflict with $variablename2 because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- xen/include/xen/init.h | 1 + 1 file changed, 1 insertion(+)