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?
Thanks,
Tejas.
