Re: [Xen-devel] [PATCH v4 2/2] xen: use SYMBOL when required

[Julien Grall <Julien.Grall@xxxxxxx>]

Hi,
On 13/11/2018 12:56, Jan Beulich wrote:
>>>> On 13.11.18 at 00:06, <sstabellini@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/alternative.c
>> +++ b/xen/arch/x86/alternative.c
>> @@ -194,7 +194,7 @@ void init_or_livepatch apply_alternatives(struct 
>> alt_instr *start,
>>        * So be careful if you want to change the scan order to any other
>>        * order.
>>        */
>> -    for ( a = base = start; a < end; a++ )
>> +    for ( a = base = start; SYMBOL(a) < SYMBOL(end); a++ )
> 
> At this point all is fine: end is allowed to point to the end of start[].

But it can also point to somewhere else. The compiler cannot know it, right?

>> @@ -33,8 +33,8 @@ static int init_percpu_area(unsigned int cpu)
>>       if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL )
>>           return -ENOMEM;
>>   
>> -    memset(p, 0, __per_cpu_data_end - __per_cpu_start);
>> -    __per_cpu_offset[cpu] = p - __per_cpu_start;
>> +    memset(p, 0, SYMBOL(__per_cpu_data_end) - SYMBOL(__per_cpu_start));
>> +    __per_cpu_offset[cpu] = (unsigned long)p - SYMBOL(__per_cpu_start);
> 
> Can't you make SYMBOL() retain the original type, such that casts
> like this one aren't needed? As soon as the compiler doesn't know
> anymore that particular globals (or statics) are used, it can't infer
> anymore that two pointers can't possibly point into the same array.

If SYMBOL() keeps the original type, then you will still substract 2 
pointers. If the compiler can't infer the cannot possibly point into the 
same array, it also cannot infer they point to the same. So that would 
be undefined, right?

Cheers,

-- 
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel