Re: [Xen-devel] [PATCH] xen: Work around Clang generating .data.rel.ro section for init-only files

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/02/16 09:47, Jan Beulich wrote:
>>>> On 22.02.16 at 17:57, <andrew.cooper3@xxxxxxxxxx> 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".

Surely we would be better seeing about fixing the build not to use
-fPIC.  Linux doesn't, so it is clearly possible.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel