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

[pinskia at gmail dot com]

> On Nov 14, 2014, at 12:54 AM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
> 
>> On 14 November 2014 08:19, Andrew Pinski <pinskia@gmail.com> 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.
> 
> Andrew, do you mind if we take that as a separate patch, I'd like to
> take Tejas' patch sooner rather than later since it gates building a
> variety of stuff some folks care about.

Yes that is ok.  This was more of since you were looking into this area kind of thing but it can wait until later. 

Thanks,
Andrew

> Cheers
> /Marcus