This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ARM as crash
- From: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: Shaun Jackman <sjackman at gmail dot com>, binutils at sources dot redhat dot com
- Date: Fri, 02 Sep 2005 13:15:23 +0100
- Subject: Re: ARM as crash
- References: <7f45d9390508260909e8bb798@mail.gmail.com> <431339B6.5010807@redhat.com> <1125398630.744.34.camel@pc960.cambridge.arm.com> <4318369A.5000604@redhat.com>
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.