https://sourceware.org/bugzilla/show_bug.cgi?id=23699
rhn <sowaac.rhn at porcupinefactory dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #11269|0 |1
is obsolete| |
--- Comment #7 from rhn <sowaac.rhn at porcupinefactory dot org> ---
Created attachment 11288
--> https://sourceware.org/bugzilla/attachment.cgi?id=11288&action=edit
Detect and reject 64-bit addresses.
Hi Nick,
I do not have emotional attachment to bugs, no need to apologise. I trust that
you know whether this one highlights a bigger issue in the architecture or can
be fixed locally.
Here's a new version of the patch. It does two things to determine whether the
address was 64-bit:
- checks whether top 32 bits are the same
- removes addresses starting with top 32 bit set but bit 31 unset, as they
couldn't have come from valid 32-bit addresses: sign extension would set the
top to 0s, no sign extension they would have to be 0s already
This strategy will leave false negatives, since both 0x00000000ffffffff and
0xffffffffffffffff are always valid addresses now.
Since seeing impossible addresses means that 64-bit code has been provided, I
decided to keep the error instead of the warning.
There's another possible way to tackle this. The code could match against
bfd->arch_info.arch, and figure out sign extension behaviour from that somehow?
Or even embed that flag in bfd_arch_info?
--
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
