This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM as crash


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]