ARM as crash
Richard Earnshaw
rearnsha@gcc.gnu.org
Fri Sep 2 14:54:00 GMT 2005
On Fri, 2005-09-02 at 12:25, Nick Clifton wrote:
> Hi Richard,
>
> > That might avoid the crash, but I'm not sure it's the 'right thing'. In
> > this case, remember that the BL instruction is PC-relative, so we do
> > need to express the branch to '0' somehow.
>
> Agreed. The attached patch makes this work by allowing relocs which
> have no associated symbol to be resolved normally. I am however worried
> about two things:
>
> * It handles the R_ARM_PC24 reloc generated by the BL instruction,
> but it also affects other relocs such as R_ARM_ABS32 and R_ARM_REL32. I
> am not sure that there can ever be valid situations where such relocs
> would need processing rather than ignoring.
>
The new thumb-2 branch relocs need similar treatment. Other than that
there's nothing on ARM with a viable addressing range. But doesn't this
need a generic solution in the MI code when reloc->pcrel is true?
> * It means that relocs against discarded sections which would before
> have just been silently mis-resolved and then ignored might now start to
> produce error messages, eg for a branch out of range. I am not sure if
> this will actually happen in real life, but I think that maybe I ought
> to update the patch to disable such errors if there is no valid symbol
> for the relocation.
I don't think we should ever quietly produce known broken code, even if
we have done so in the past. Treat this as an enhanced QoI -- we can
now tell you that the code is wrong...
R.
More information about the Binutils
mailing list