[Bug debug/109161] New: Bad CTF generated for stub in function scope

[Bug debug/109161] New: Bad CTF generated for stub in function scope

[ibhagat at gcc dot gnu.org]

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

            Bug ID: 109161
           Summary: Bad CTF generated for stub in function scope
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ibhagat at gcc dot gnu.org
  Target Milestone: ---

$ cat t.c 
void set_cpu_arch (void) {
    typedef struct arch_stack_entry {
        const struct arch_stack_entry *prev;
    } arch_stack_entry;
    static arch_stack_entry *arch_stack_top;
}

$ gcc -gctf -g3 -c t.c

$ objdump --ctf=.ctf t.o will hang.

The hang is because the compiler spits incorrect CTF. 

Byte offsets (which point to the location of the various sub-sections in the
CTF section) encoded in the CTF header as seen via poke:
  ...
  cth_funcoff=0U#B,
  cth_objtidxoff=4U#B,
  cth_funcidxoff=4U#B,
  cth_varoff=8U#B,
  cth_typeoff=8U#B,
  cth_stroff=96U#B,
  ...

 -- The generated CTF section has one function object, and no variables as can
be seen from the offsets in the header. This is OK. 
 --There are however, generated types; Further, a subset of which are incorrect
(see below).

(poke) ctf_dump_all_types(ctf)
Types:
   1:  (kind 1) integer void (size 0) (signed)
   2:  (kind 5) function set_cpu_arch --> ID 1: (kind 1) integer void (size 0)
   3:  (kind 6) struct arch_stack_entry (size 8)
        [0U#b] prev (ID 5)
        [0U#b]  (ID 3)
   4:  (kind 12) const  --> ID 3: (kind 6) struct arch_stack_entry (size 8)
   5:  (kind 3) pointer  --> ID 4: (kind 12) const  --> ID 3: (kind 6) struct
arch_stack_entry (size 8)

[Problem #1] A struct with two members, one of which is unnamed.  The type as
defined by the user has one member named prev in the struct => The generated
CTF is incorrect.
[Problem #2] Well, why is there any generated CTF at all ?  Both the variable
and the defined type are function-scope; In CTF, only top-level types,
functions, variables are to be described.

[Bug debug/109161] Bad CTF generated for stub in function scope

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>The hang is because the compiler spits incorrect CTF. 

Did you also file a binutils bug for the objdump issue? It seems like it should
not hang for invalid input ...

[Bug debug/109161] Bad CTF generated for stub in function scope

[nix at esperi dot org.uk]

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

Nix <nix at esperi dot org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nix at esperi dot org.uk

--- Comment #2 from Nix <nix at esperi dot org.uk> ---
It definitely shouldn't hang for invalid input, but that sort of proof against
invalid input isn't even implemented for the deduplicator yet, let alone every
other thing that recurses over the type graph. It's on the todo list... and
it's not specific to objdump at all: ctf_dump (objdump/readelf),
ctf_type_rvisit, ctf_type_compat, even foundational libctf stuff like
ctf_type_resolve would hang if, say, we had a CTF_K_CONST node pointing to
itself, even indirectly. This does mean that anything we use to detect cycles
must be *cheap*.

Now I was assuming I could only implement cycle-detection efficiently for the
deduplicator (which would usually suffice, since linking is the first thing
that is usually done to compiler-generated CTF) -- but it occurs to me now that
I could use a similar technique in ctf_type_rvisit, which will handle ctf_dump:
I can probably do the same for the other recursive type-traversing functions,
and handle all of them with the same cycle-detection code, and then CTF
manipulation on raw object files would be safe against cycles too. The
algorithm in question (one of Hellman's more obscure) cannot guarantee
immediate detection of cycles, but it will always detect them eventually, which
is good enough for this application. That's the price we pay for spotting
cycles in constant space with almost no time overhead for the common, acyclic
case.

[Bug debug/109161] Bad CTF generated for stub in function scope

[ibhagat at gcc dot gnu.org]

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

--- Comment #3 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
Excerpt from the generated DWARF debug info:
 <1><32>: Abbrev Number: 3 (DW_TAG_subprogram)
    <33>   DW_AT_external    : 1
    <33>   DW_AT_name        : (indirect string, offset: 0x12c4): set_cpu_arch
    ...
    <4c>   DW_AT_sibling     : <0x8e>
 <2><50>: Abbrev Number: 4 (DW_TAG_structure_type)
    <51>   DW_AT_name        : (indirect string, offset: 0x227c):
arch_stack_entry
    ... 
    <59>   DW_AT_sibling     : <0x70>
 <3><5d>: Abbrev Number: 5 (DW_TAG_member)
    <5e>   DW_AT_name        : (indirect string, offset: 0x79a): prev
    ...
    <65>   DW_AT_type        : <0x8e>
    <69>   DW_AT_data_member_location: 0
 <3><6a>: Abbrev Number: 6 (DW_TAG_const_type)
    <6b>   DW_AT_type        : <0x50>
 <3><6f>: Abbrev Number: 0
 <2><70>: Abbrev Number: 7 (DW_TAG_typedef)
    <71>   DW_AT_name        : (indirect string, offset: 0x227c):
arch_stack_entry
    ...
    <78>   DW_AT_type        : <0x50>
 <2><7c>: Abbrev Number: 8 (DW_TAG_variable)
    <7d>   DW_AT_name        : (indirect string, offset: 0x9c5): arch_stack_top
    ...
    <84>   DW_AT_type        : <0x88>
 <2><88>: Abbrev Number: 1 (DW_TAG_pointer_type)
    <89>   DW_AT_byte_size   : 8
    <89>   DW_AT_type        : <0x70>
 <2><8d>: Abbrev Number: 0
 <1><8e>: Abbrev Number: 1 (DW_TAG_pointer_type)
    <8f>   DW_AT_byte_size   : 8
    <8f>   DW_AT_type        : <0x6a>
 <1><93>: Abbrev Number: 0

I see the issues to be the result of:
#1. The gen_ctf_sou_type function is processing
   <3><6a>: Abbrev Number: 6 (DW_TAG_const_type)
   as a member of the struct.
#2. The top-level DIE 
   <1><8e>: Abbrev Number: 1 (DW_TAG_pointer_type)
   is being processed by ctf_do_die.