https://sourceware.org/bugzilla/show_bug.cgi?id=26757
sourceware-bugzilla at jdrake dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sourceware-bugzilla@jdrake.
| |com,
| |tnfchris at sourceware dot org
--- Comment #8 from sourceware-bugzilla at jdrake dot com ---
We seem to have run into this bug (or something similar to it) over at
https://github.com/msys2/MINGW-packages/issues/8868. The fix for PR26659 got
rid of the error, but its assumptions don't quite hold in this case.
> One down side of this is that it does break the common convention that the
> call
> be to sym at 0x0. i.e. before you'd get
>
> 401015: 74 05 je 40101c
> 401017: e8 e4 ef bf ff callq 0
>
> and now you get
>
> 140001015: 74 05 je 14000101c
> 140001017: e8 e4 ef ff bf call 100000000
>
> since the call is PC_REL there's no way to get the range large enough to
> resolve to 0. As such I have chosen to leave it as the furthest simple
> range
> that we can still represent.
>
> By only ignoring the error we leave the symbol value itself to still be 0
> such that the if(<symbol>) checks still work correctly.
In this case, the generated code (expanded up a couple of instructions) looks
like
0x00007ffb2ba04818 <+24>: lea -0x60f1481f(%rip),%rax #
0x7ffacaaf0000
0x00007ffb2ba0481f <+31>: test %rax,%rax
0x00007ffb2ba04822 <+34>: je 0x7ffb2ba04829
0x00007ffb2ba04824 <+36>: call 0x7ffacaaf0000
So the fact that the compiler decided to use lea in its if(<symbol>) check
means it was subject to the same range limitations as the call, and therefore
can never evaluate 0.
--
You are receiving this mail because:
You are on the CC list for the bug.
