Re: [AArch64, Patch] Add range-check for Symbol + offset addressing.

[Andrew Pinski <pinskia at gmail dot com>]

On Fri, Nov 14, 2014 at 12:50 AM, Tejas Belagod <tejas.belagod@arm.com> wrote:
> On 14/11/14 08:19, Andrew Pinski wrote:
>>
>> On Fri, Nov 14, 2014 at 12:12 AM, Tejas Belagod <tejas.belagod@arm.com>
>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> Following the discussion here
>>> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02237.html, this has been
>>> tracked down to a range-checking bug with symbol + offset style
>>> addressing
>>> with adrp where we allowed any arbitrary offset and this would cause
>>> truncation of final addresses when relocations were being resolved by ld.
>>> When we retreive symbol + offset address, we have to make sure the offset
>>> does not cause overflow of the final address.  But we have no way of
>>> knowing
>>> the address of symbol at compile time
>>> so we can't accurately say if the distance between the PC and symbol +
>>> offset is outside the addressible range of +/-1M in the TINY code model.
>>> So
>>> we rely on images not being greater than 1M and cap the offset at 1M and
>>> anything beyond 1M will have to be loaded using an alternate mechanism.
>>> Similarly for the SMALL code model the offset has been capped at 4G.
>>>
>>> The cap value for the offset in each code model is open to debate.
>>>
>>> All testing done with Alan's workaround
>>> patch(https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01509.html) reversed.
>>>
>>> bootstrapped aarch64-linux.
>>>
>>> OK for trunk?
>>
>>
>> This looks like a better fix than I would have came up with.
>> Since you are touching this area you might want to look into this issue:
>> I notice SYMBOL_REF_WEAK (x) is true for references(decls) which are
>> comdat's which are declared in the translation unit.  So force them to
>> memory when really we know they are declared and don't have a value of
>> zero so they will fit in the medium code model.  This happens with
>> vtables and we lose some performance because of this.
>>
>
> Do you have a bugzilla ticket open for this?


I do now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874 .

Thanks,
Andrew

>
> Thanks,
> Tejas.
>
>