[Bug debug/94469] lto abstract variable emitted as concrete decl (ada test-case)

vries at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Apr 7 12:09:30 GMT 2020


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

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> (In reply to Tom de Vries from comment #8)
> > (In reply to Richard Biener from comment #7)
> > > (In reply to Richard Biener from comment #6)
> > > > Btw, I still wonder how it works with abstract functions, inline and
> > > > concrete instances.  Works in gdb, that is - will dig into it a bit after
> > > > lunch.
> > > 
> > > So here I see us (without LTO) putting DW_AT_location attributes on the
> > > abstract instance copy.  That kind-of makes it not abstract anymore, no?
> > > But that way we avoid emitting multiple DIEs for local statics.  With
> > > -flto the same problem appears there because we cannot annotate the
> > > early CUs DIE with a location so the concrete instance copy
> > > gets [generated and] the location.
> > > 
> > > So while I intended to have the early CUs behave like fully abstract
> > > the actual DWARF is different.  I understand that if I emit the early CU as
> > > partial unit it becomes abstract?
> > 
> > Well, that's my theory.
> > 
> > I've created a minimal dwarf assembler variant corresponding to the C
> > test-case (with only var aaa), and I could reproduce the problem, however
> > after changing the tag to DW_TAG_partial_unit still a symbol table for that
> > partial unit was created. It seems that the inter-cu ref handling code is
> > responsible for that. I'll try to fix this.
> > 
> > >  Note we do emit DW_AT_const_value
> > > to early optimized out decls - would those still be found when the early CU
> > > is partial [and not imported anywhere]?
> > 
> > I think so, but I could check with the dwarf assembler test-case.
> 
> OK, so that doesn't work anymore.
> 
> static const int i = 1;
> 
> int main()
> {
>   return i;
> }
> 
> with -O2 -flto -g and DW_TAG_compile_unit I see
> 
> (gdb) start
> Temporary breakpoint 1 at 0x4003a0: file t.c, line 5.
> Starting program: /home/abuild/rguenther/obj-gcc-g/gcc/a.out
> 
> Temporary breakpoint 1, main () at t.c:5
> 5         return i;
> (gdb) p i
> 1
> 
> while when using DW_TAG_partial_unit:
> 
> (gdb) p i
> No symbol "i" in current context.
> 
>   Compilation Unit @ offset 0xc7:
>    Length:        0x3d (32-bit)
>    Version:       4
>    Abbrev Offset: 0x64
>    Pointer Size:  8
>  <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     <d3>   DW_AT_producer    : (indirect string, offset: 0x1d0): GNU GIMPLE
> 10.0
> .1 20200406 (experimental) -mtune=generic -march=x86-64 -g -g -O2 -O2
> -fno-openm
> p -fno-openacc -fno-pie -fltrans
>     <d7>   DW_AT_language    : 12       (ANSI C99)
>     <d8>   DW_AT_name        : (indirect string, offset: 0x250): <artificial>
>     <dc>   DW_AT_comp_dir    : (indirect string, offset: 0x25d):
> /abuild/rguenth
> er/obj-gcc-g/gcc
>     <e0>   DW_AT_ranges      : 0x40
>     <e4>   DW_AT_low_pc      : 0x0
>     <ec>   DW_AT_stmt_list   : 0xe9
>  <1><f0>: Abbrev Number: 2 (DW_TAG_subprogram)
>     <f1>   DW_AT_abstract_origin: <0x13c>
>     <f5>   DW_AT_low_pc      : 0x4003a0
>     <fd>   DW_AT_high_pc     : 0x6
>     <105>   DW_AT_frame_base  : 1 byte block: 9c       
> (DW_OP_call_frame_cfa)
>     <107>   DW_AT_GNU_all_call_sites: 1
>  <1><107>: Abbrev Number: 0
>   Compilation Unit @ offset 0x108:
>    Length:        0x3d (32-bit)
>    Version:       4
>    Abbrev Offset: 0x88
>    Pointer Size:  8
>  <0><113>: Abbrev Number: 1 (DW_TAG_partial_unit)
>     <114>   DW_AT_producer    : (indirect string, offset: 0x27d): GNU C17
> 10.0.1
>  20200406 (experimental) -mtune=generic -march=x86-64 -g -O2 -flto
>     <118>   DW_AT_language    : 12      (ANSI C99)
>     <119>   DW_AT_name        : t.c
>     <11d>   DW_AT_comp_dir    : (indirect string, offset: 0x25d):
> /abuild/rguent
> her/obj-gcc-g/gcc
>     <121>   DW_AT_stmt_list   : 0x127
>  <1><125>: Abbrev Number: 2 (DW_TAG_variable)
>     <126>   DW_AT_name        : i
>     <128>   DW_AT_decl_file   : 1
>     <129>   DW_AT_decl_line   : 1
>     <12a>   DW_AT_decl_column : 18
>     <12b>   DW_AT_type        : <0x137>
>     <12f>   DW_AT_const_value : 1
>  <1><130>: Abbrev Number: 3 (DW_TAG_base_type)
>     <131>   DW_AT_byte_size   : 4
>     <132>   DW_AT_encoding    : 5       (signed)
>     <133>   DW_AT_name        : int
>  <1><137>: Abbrev Number: 4 (DW_TAG_const_type)
>     <138>   DW_AT_type        : <0x130>
>  <1><13c>: Abbrev Number: 5 (DW_TAG_subprogram)
>     <13d>   DW_AT_external    : 1
>     <13d>   DW_AT_name        : (indirect string, offset: 0x2ce): main
>     <141>   DW_AT_decl_file   : 1
>     <142>   DW_AT_decl_line   : 3
>     <143>   DW_AT_decl_column : 5
>     <144>   DW_AT_type        : <0x130>
>  <1><148>: Abbrev Number: 0
> 

Ack, I've managed to reproduce this using a dwarf assembly test-case (PR
gdb/25796 - "Symbol with inherited DW_AT_const_value not found" @
https://sourceware.org/bugzilla/show_bug.cgi?id=25796), and submitted a gdb
patch for this.

Note that the problem is specific to gdb's partial symbol tables feature, so
that problem doesn't occur when using -readnow.

> I understand that if I would again add imports this would likely be resolved
> but at the expense of re-creating the original issue (but just with two
> instances rather than three)?

Agreed.


More information about the Gcc-bugs mailing list