PR41357: libgomp broken debug info vs. TLS emu

PR41357: libgomp broken debug info vs. TLS emu

[Dave Korn]

    Hi all, and Ping! Alex :)

  Since the recent vta changes, libgomp build seems to be broken on at least
some platforms that rely on tls emulation.  All references to tls variables in
the generated source are prefixed with "__emutls_v" by the action of
get_emutls_object_name() in varasm.c, but the debug information ends up with a
reference to the un-prefixed original version of the variable's name.

  I'm looking at this now, but it's a new area of the compiler to me, so if
anyone reading that problem description gets a light-bulb pinging on above
their head and knows exactly where I should be looking to figure out how the
real and debug info var names diverge in this way, please do drop me a note!

    cheers,
      DaveK

Re: PR41357: libgomp broken debug info vs. TLS emu

[Dave Korn]

Dave Korn wrote:
>     Hi all, and Ping! Alex :)
> 
>   Since the recent vta changes, libgomp build seems to be broken on at least
> some platforms that rely on tls emulation.  All references to tls variables in
> the generated source are prefixed with "__emutls_v" by the action of
> get_emutls_object_name() in varasm.c, but the debug information ends up with a
> reference to the un-prefixed original version of the variable's name.

  The problem appears to lie in the generation of the NOTE_VAR_LOCATION for a
local variable in the affected function:

> (gdb) call debug_tree(0x7fe190c0)
>  <var_decl 0x7fe190c0 gomp_tls_data
>     type <record_type 0x7fe7df90 gomp_thread asm_written type_0 BLK
>         size <integer_cst 0x7fe2a8e0 constant 416>
>         unit size <integer_cst 0x7fe87dc0 constant 52>
>         align 32 symtab 2145789512 alias set 7 canonical type 0x7fe7df90
>         fields <field_decl 0x7fe18ca0 fn type <pointer_type 0x7fda5e10>
>             unsigned SI file /gnu/gcc/gcc/libgomp/libgomp.h line 327 col 10
>             size <integer_cst 0x7fef0580 constant 32>
>             unit size <integer_cst 0x7fef0320 constant 4>
>             align 32 offset_align 128
>             offset <integer_cst 0x7fef0340 constant 0>
>             bit offset <integer_cst 0x7fef0b60 constant 0> context <record_type 0x7fe7df90 gomp_thread> chain <field_decl 0x7fe18d00 data>> context <translation_unit_decl 0x7fcac550 D.3329>
>         pointer_to_this <pointer_type 0x7fe7e230> chain <type_decl 0x7fe7e000 D.2396>>
>     addressable used public external tls-local-exec BLK file /gnu/gcc/gcc/libgomp/libgomp.h line 361 col 36 size <integer_cst 0x7fe2a8e0 416> unit size <integer_cst 0x7fe87dc0 52>
>     align 32
>     (mem/s/c:BLK (symbol_ref:SI ("gomp_tls_data") [flags 0x42] <var_decl 0x7fe190c0 gomp_tls_data>) [7 gomp_tls_data+0 S52 A32]) chain <function_decl 0x7fdfb000 gomp_new_icv>>
> (gdb)

  Notice that in this var_decl, the DECL_TLS_MODEL is "tls-local-exec", but
this is not reflected in the RTL, which has no tls model set in bits 3:5 of
the flags.  I'm now about to start digging into where this note is created; as
before, if anyone has any pointers or theories, that would really help speed
me on my way.

    cheers,
      DaveK