public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/110439] New: Missing DW_TAG_typedef for variable with attribute of typedef'd type
@ 2023-06-27 18:32 david.faust at oracle dot com
  2023-06-27 18:39 ` [Bug debug/110439] " pinskia at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: david.faust at oracle dot com @ 2023-06-27 18:32 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 110439
           Summary: Missing DW_TAG_typedef for variable with attribute of
                    typedef'd type
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david.faust at oracle dot com
  Target Milestone: ---

$ cat typedef-skip-1.c
typedef int foo;
foo __attribute__((may_alias)) attr_foo;
foo plain_foo;

DW_AT_type in the variable DIE for 'attr_foo' refers to the base int type,
while for 'plain_foo' it refers to the typedef DIE I would expect: 

$ gcc -g -c typedef-skip-1.c
$ readelf -wi typedef-skip-1.o

 <0><c>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <d>   DW_AT_producer    : (indirect string, offset: 0): GNU C17 12.2.0
-mtune=generic -march=x86-64 -g -fasynchronous-unwind-tables
    <11>   DW_AT_language    : 29       (C11)
    <12>   DW_AT_name        : (indirect line string, offset: 0):
typedef-skip-1.c
    <16>   DW_AT_comp_dir    : (indirect line string, offset: 0x11):
/home/dfaust/playpen
    <1a>   DW_AT_stmt_list   : 0
 <1><1e>: Abbrev Number: 3 (DW_TAG_typedef)
    <1f>   DW_AT_name        : foo
    <23>   DW_AT_decl_file   : 1
    <24>   DW_AT_decl_line   : 1
    <25>   DW_AT_decl_column : 13
    <26>   DW_AT_type        : <0x2a>
 <1><2a>: Abbrev Number: 4 (DW_TAG_base_type)
    <2b>   DW_AT_byte_size   : 4
    <2c>   DW_AT_encoding    : 5        (signed)
    <2d>   DW_AT_name        : int
 <1><31>: Abbrev Number: 1 (DW_TAG_variable)
    <32>   DW_AT_name        : (indirect string, offset: 0x4c): attr_foo
    <36>   DW_AT_decl_file   : 1
    <36>   DW_AT_decl_line   : 2
    <37>   DW_AT_decl_column : 32
    <38>   DW_AT_type        : <0x2a>
    <3c>   DW_AT_external    : 1
    <3c>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <1><46>: Abbrev Number: 1 (DW_TAG_variable)
    <47>   DW_AT_name        : (indirect string, offset: 0x55): plain_foo
    <4b>   DW_AT_decl_file   : 1
    <4b>   DW_AT_decl_line   : 3
    <4c>   DW_AT_decl_column : 5
    <4d>   DW_AT_type        : <0x1e>
    <51>   DW_AT_external    : 1
    <51>   DW_AT_location    : 9 byte block: 3 4 0 0 0 0 0 0 0  (DW_OP_addr: 4)
 <1><5b>: Abbrev Number: 0

DWARF output by clang has the DW_TAG_typedef DIE in DW_AT_type for both
variables:

$ clang -c -g typedef-skip-1.c -o typedef-skip-1.o.clang
$ readelf -wi typedef-skip-1.o.clang

 <1><1e>: Abbrev Number: 2 (DW_TAG_variable)
    <1f>   DW_AT_name        : (indexed string: 0x3): attr_foo
    <20>   DW_AT_type        : <0x29>
    <24>   DW_AT_external    : 1
    <24>   DW_AT_decl_file   : 0
    <25>   DW_AT_decl_line   : 2
    <26>   DW_AT_location    :  (DW_OP_addrx <0>)
 <1><29>: Abbrev Number: 3 (DW_TAG_typedef)
    <2a>   DW_AT_type        : <0x31>
    <2e>   DW_AT_name        : (indexed string: 0x5): foo
    <2f>   DW_AT_decl_file   : 0
    <30>   DW_AT_decl_line   : 1
 <1><31>: Abbrev Number: 4 (DW_TAG_base_type)
    <32>   DW_AT_name        : (indexed string: 0x4): int
    <33>   DW_AT_encoding    : 5        (signed)
    <34>   DW_AT_byte_size   : 4
 <1><35>: Abbrev Number: 2 (DW_TAG_variable)
    <36>   DW_AT_name        : (indexed string: 0x6): plain_foo
    <37>   DW_AT_type        : <0x29>
    <3b>   DW_AT_external    : 1
    <3b>   DW_AT_decl_file   : 0
    <3c>   DW_AT_decl_line   : 3
    <3d>   DW_AT_location    :  (DW_OP_addrx <0x1>)
 <1><40>: Abbrev Number: 0


Note this isn't strictly related to 'may_alias', I just found it to be a
reliable
reproducer.  I tripped on this while working on a patch to support a BPF
feature,
the btf_type_tag attribute.


I think this happens because this lookup in modified_type_die:

  /* If we do, then we can just use its DIE, if it exists.  */
  if (qualified_type)
    {
      mod_type_die = lookup_type_die (qualified_type);

finds the typedef DIE for the un-__attribute__-ed use 'foo', but
returns NULL for the __attribute__-ed use of 'foo':

Breakpoint 6, modified_type_die (type=<integer_type 0x7ffff77adf18 foo>,
cv_quals=0, reverse=false, 
    context_die=<dw_die_ref 0x7ffff762d190 DW_TAG_compile_unit>) at
../../../gcc/gcc/dwarf2out.cc:13631
(gdb) pt type
 <integer_type 0x7ffff77ad690 foo asm_written SI
    size <integer_cst 0x7ffff7602fd8 type <integer_type 0x7ffff76210a8
bitsizetype> constant 32>
    unit-size <integer_cst 0x7ffff7625000 type <integer_type 0x7ffff7621000
sizetype> constant 4>
    align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff76215e8
    attributes <tree_list 0x7ffff77ae348
        purpose <identifier_node 0x7ffff77c0e10 may_alias>> precision:32 min
<integer_cst 0x7ffff7602f90 -2147483648> max <integer_cst 0x7ffff7602fa8
2147483647>>
...
13699     if (qualified_type)
(gdb) 
13701         mod_type_die = lookup_type_die (qualified_type);
(gdb) 
13706         if (mod_type_die
(gdb) p mod_type_die
$1 = <dw_die_ref 0x0>

Then recurses with

  return modified_type_die (DECL_ORIGINAL_TYPE (name), cv_quals,
                                      reverse, context_die);

Where DECL_ORIGINAL_TYPE (name) is a plain integer type:

 <integer_type 0x7ffff76215e8 int public SI
    size <integer_cst 0x7ffff7602fd8 type <integer_type 0x7ffff76210a8
bitsizetype> constant 32>
    unit-size <integer_cst 0x7ffff7625000 type <integer_type 0x7ffff7621000
sizetype> constant 4>
    align:32 warn_if_not_align:0 symtab:-142864960 alias-set -1 canonical-type
0x7ffff76215e8 precision:32 min <integer_cst 0x7ffff7602f90 -2147483648> max
<integer_cst 0x7ffff7602fa8 2147483647>
    pointer_to_this <pointer_type 0x7ffff7629b28>>


I am not 100% sure whether the GCC output is "strictly incorrect" DWARF, but at
the least
it is an inconsistency between clang and GCC.

Observed with gcc (Debian 12.2.0-14) 12.2.0 and git master (GCC) 14.0.0
20230627 (experimental) on x86_64

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/110439] Missing DW_TAG_typedef for variable with attribute of typedef'd type
  2023-06-27 18:32 [Bug debug/110439] New: Missing DW_TAG_typedef for variable with attribute of typedef'd type david.faust at oracle dot com
@ 2023-06-27 18:39 ` pinskia at gcc dot gnu.org
  2023-06-27 18:45 ` david.faust at oracle dot com
  2023-06-28  7:54 ` rguenth at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-27 18:39 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The may_alias does not apply directly to variables nor their types ....

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/110439] Missing DW_TAG_typedef for variable with attribute of typedef'd type
  2023-06-27 18:32 [Bug debug/110439] New: Missing DW_TAG_typedef for variable with attribute of typedef'd type david.faust at oracle dot com
  2023-06-27 18:39 ` [Bug debug/110439] " pinskia at gcc dot gnu.org
@ 2023-06-27 18:45 ` david.faust at oracle dot com
  2023-06-28  7:54 ` rguenth at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: david.faust at oracle dot com @ 2023-06-27 18:45 UTC (permalink / raw)
  To: gcc-bugs

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

David Faust <david.faust at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jemarch at gcc dot gnu.org

--- Comment #2 from David Faust <david.faust at oracle dot com> ---
(In reply to Andrew Pinski from comment #1)
> The may_alias does not apply directly to variables nor their types ....

I use may_alias here as a placeholder, since it persists in the TREE
representation through this point.  I found this while implementing a new
attribute (btf_type_tag, a BPF feature) which does apply directly to types with
a similar representation in the TREE, which triggered the same behavior.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/110439] Missing DW_TAG_typedef for variable with attribute of typedef'd type
  2023-06-27 18:32 [Bug debug/110439] New: Missing DW_TAG_typedef for variable with attribute of typedef'd type david.faust at oracle dot com
  2023-06-27 18:39 ` [Bug debug/110439] " pinskia at gcc dot gnu.org
  2023-06-27 18:45 ` david.faust at oracle dot com
@ 2023-06-28  7:54 ` rguenth at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-06-28  7:54 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-06-28
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
it works fine with

foo const attr_foo;

where we generate

 <1><1e>: Abbrev Number: 3 (DW_TAG_typedef)
    <1f>   DW_AT_name        : foo
    <23>   DW_AT_decl_file   : 1
    <24>   DW_AT_decl_line   : 1
    <25>   DW_AT_decl_column : 13
    <26>   DW_AT_type        : <0x2f>
 <1><2a>: Abbrev Number: 4 (DW_TAG_const_type)
    <2b>   DW_AT_type        : <0x1e>
 <1><36>: Abbrev Number: 1 (DW_TAG_variable)
    <37>   DW_AT_name        : (indirect string, offset: 0xa): attr_foo
    <3b>   DW_AT_decl_file   : 1
    <3b>   DW_AT_decl_line   : 2
    <3c>   DW_AT_decl_column : 11
    <3d>   DW_AT_type        : <0x2a>
    <41>   DW_AT_external    : 1
    <41>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

to GCC the attribute generates a similar type variant but there's no
way to emit the "qualification" in dwarf but it looks like for consistency
we should then fall back to the typedef DIE, not the base type DIE.

Confirmed.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-06-28  7:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-27 18:32 [Bug debug/110439] New: Missing DW_TAG_typedef for variable with attribute of typedef'd type david.faust at oracle dot com
2023-06-27 18:39 ` [Bug debug/110439] " pinskia at gcc dot gnu.org
2023-06-27 18:45 ` david.faust at oracle dot com
2023-06-28  7:54 ` rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).