On Fri, Nov 14, 2014 at 12:50 AM, Tejas Belagod <tejas.bela...@arm.com> wrote: > On 14/11/14 08:19, Andrew Pinski 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. >> > > 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. > >
