[Bug ld/26757] Cross and Native GDB Fails to Build on Cygwin

[sourceware-bugzilla at jdrake dot com]

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.