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.
