http://sourceware.org/bugzilla/show_bug.cgi?id=12848
Dave Martin <dave.martin at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #5 from Dave Martin <dave.martin at linaro dot org> 2011-07-04
15:54:35 UTC ---
(In reply to comment #4)
> Hi Dave,
>
> I have checked in a patch which should address this problem. Please let me
> know if I have missed any of the checks though.
>
> Cheers
> Nick
Some things are now fixed, but forward 32-bit conditional branches with ranges
from . + 4 + 0x100000 to . + 4 + 0x1ffffe are still not handled correctly.
Reverse branches with ranges of the same magnitude are correctly rejected
though.
It also occurred to me to check bl and blx instructions, since these have an
encoding closely related to the 32-bit unconditional branch, and the same
range. It turns out that these are wongly range-checked in the same way that
the 32-bit unconditional branches were previously wrongly checked.
I'll attach my extended testcase. I also have a patch which attempts to tidy
up the branch range fixups, and reduce the amount of magic numbers floating
around the code. I'm not sure whether it's appropriate/necessary to check
alignment at the same time as checking the range, and it's possible that the
macros I've added duplicate functionality already implemented somewhere else...
Finally, should we get rid of all the variant branch-out-of-range messages? I
think that BAD_RANGE is actually adequately descriptive for all these cases.
Cheers
---Dave
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
