On 14 November 2014 08:19, Andrew Pinski <pins...@gmail.com> wrote: > On Fri, Nov 14, 2014 at 12:12 AM, Tejas Belagod <tejas.bela...@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. Cheers /Marcus
