>>> On 22.02.16 at 17:57, <andrew.coop...@citrix.com> wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -38,7 +38,7 @@ static const unsigned char k8nops[] __initconst = {
> K8_NOP7,
> K8_NOP8
> };
> -static const unsigned char * const k8_nops[ASM_NOP_MAX+1] = {
> +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = {
> NULL,
> k8nops,
> k8nops + 1,
> @@ -62,7 +62,7 @@ static const unsigned char p6nops[] __initconst = {
> P6_NOP7,
> P6_NOP8
> };
> -static const unsigned char * const p6_nops[ASM_NOP_MAX+1] = {
> +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = {
> NULL,
> p6nops,
> p6nops + 1,
Afaict this will cause the same section type conflict issue as did
the command line parameter constification change that I needed
to revert yesterday. I'm afraid there's no way around introducing
a sibling to __initconst (e.g. __initrelro or __initconst_r) specifying
another section name (e.g. .init.rodata.rel), which then needs to
be used on data objects incurring relocations. And iirc that was
also the reason why these annotation have got left off originally
here.
The issue is that with -fPIC these sections needing relocations
need to be marked writable even if the objects are "const".
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
