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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.16 at 11:10, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

Linux runs in the top 2Gb of address space, using -mcmodel=kernel.
We can't do that.

Jan


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