[Bug debug/82630] Bogus DW_AT_GNU_call_site_value

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is the assembler's special treatment of _GLOBAL_OFFSET_TABLE_, that
.long _GLOBAL_OFFSET_TABLE_ or .quad _GLOBAL_OFFSET_TABLE_ on x86 doesn't
actually assemble as normal relocation against that symbol, but as a special
relocation.
The reason why we end up with this is that during var-tracking/dwarf2out in
this case we fail to prove that %ebx at that point contains
_GLOBAL_OFFSET_TABLE_ and so delegitimization offsers the last possibility,
verification of that at debug time.

The question is if it is actually possible to somehow emit an address of
_GLOBAL_OFFSET_TABLE_ into the debug info when
        .byte   0x3     # DW_OP_addr
        .long   _GLOBAL_OFFSET_TABLE_
doesn't work.  I've tried
.set .LC1000 = _GLOBAL_OFFSET_TABLE_
.long .LC1000
but that doesn't work either.  If we have some local symbol emitted in
allocatable sections, we could emit:
.byte 0x3 # DW_OP_addr
.long .LC0
.byte 0x3 # DW_OP_addr
.long .LC0@GOTOFF
.byte 0x1c # DW_OP_minus
because symbol@GOTOFF is symbol - _GLOBAL_OFFSET_TABLE_, but that is very nasty
and large.

In the end, it is pitty that for the R_386_GOTPC etc. relocations the x86
assembler doesn't use some @gotpc or similar suffixes; or we could get away
with a suffix that would undo this special handling of _GLOBAL_OFFSET_TABLE_
symbol.