[Bug debug/105089] New: CTF for a defined extern variable is ambiguous

[Bug debug/105089] New: CTF for a defined extern variable is ambiguous

[ibhagat at gcc dot gnu.org]

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

            Bug ID: 105089
           Summary: CTF for a defined extern variable is ambiguous
           Product: gcc
           Version: 12.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 extern.c
extern const char a[];
const char a[] = "testme";

$ gcc -gctf -dA -S extern.c

excerpt from extern.s:

        .long   0x5     # objtinfo_var_type
        .long   0x8     # objtinfo_var_type
        .long   0xb     # objtinfo_name
        .long   0x1f    # objtinfo_name
        .long   0xb     # ctv_name
        .long   0x5     # ctv_typeidx
        .long   0x1f    # ctv_name
        .long   0x8     # ctv_typeidx

There are TWO CTF variable records (two ctv_name, each with a ctv_typeidx). 
Further, two CTF objects records as well.

$ gcc -gctf -c extern.c
$ objdump --ctf=.ctf extern.o
shows:

  Variables:
    a ->  8: const const char [7] (size 0x7) -> 7: const char [7] (size 0x7)
    a ->  5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0)

  Types:
     1: char (size 0x1)
        [0x0] (ID 0x1) (kind 1) char  (aligned at 0x1, format 0x3, offset:bits
0x0:0x8)
     2: const char (size 0x1) -> 1: char (size 0x1)
        [0x0] (ID 0x2) (kind 12) const char  (aligned at 0x1)
     3: void (size 0x0)
        [0x0] (ID 0x3) (kind 1) void  (aligned at 0x0, format 0x1, offset:bits
0x0:0x0)
     4: const char [0] (size 0x0)
        [0x0] (ID 0x4) (kind 4) const char [0]  (aligned at 0x1)
     5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0)
        [0x0] (ID 0x5) (kind 12) const const char [0]  (aligned at 0x1)
     6: long unsigned int (size 0x8)
        [0x0] (ID 0x6) (kind 1) long unsigned int  (aligned at 0x8, format 0x0,
offset:bits 0x0:0x40)
     7: const char [7] (size 0x7)
        [0x0] (ID 0x7) (kind 4) const char [7]  (aligned at 0x1)
     8: const const char [7] (size 0x7) -> 7: const char [7] (size 0x7)
        [0x0] (ID 0x8) (kind 12) const const char [7]  (aligned at 0x1)

  Strings:
    0: 
    1: char
    6: void
    b: a
    d: long unsigned int
    1f: a
    ...

Note, two entries in the "Variables:" sub-section, and two strings "a" for the
variable name in the "Strings:" sub-section.

In the above case, the compiler must emit only one entry for the variable a
with type specified as const char [7].

Note that, CTF format cannot differentiate between a non-defining extern
variable declaration vs. a defining variable declaration (unlike DWARF). So,
emitting two CTF variable records, one for the non-defining decl and another
for the defining decl will create ambiguity for the linker/CTF reader.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like this is a defect in CTF then?  Which should it pick?  The more
"specific"?  What if there are two?

static const char a[] = "testme";
void foo () { puts (a); }
int main()
{
  extern const char a[];
  puts (a);
  foo ();
}

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[ibhagat at gcc dot gnu.org]

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

--- Comment #2 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
Regarding this above-mentioned case of two variables (one inside the function),
CTF emits debug information for file-scope and global-scope variables only. So
in this example, the declaration of a inside the function should not be
considered from CTF perspective.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[ibhagat at gcc dot gnu.org]

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

--- Comment #3 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
Re: the more "specific" one?, I think if the compiler picks the type from the
defining declaration of the variable, that will be useful (and correct I think)
CTF debug information.

So, for the following-

case 1
------
$ cat a.c
extern const char a[];
const char a[] = "testme";

The compiler should emit CTF type for variable a as const char[7]

If, however, there is a single non-defining decl as follows-

case 2
------
$ cat b.c
extern int a;

The compiler should emit CTF type for variable as as int.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Indu Bhagat from comment #2)
> Regarding this above-mentioned case of two variables (one inside the
> function), CTF emits debug information for file-scope and global-scope
> variables only. So in this example, the declaration of a inside the function
> should not be considered from CTF perspective.

But a is in the global scope ....
Just not injected into the global scope for that translation unit.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[ibhagat at gcc dot gnu.org]

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

--- Comment #5 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Indu Bhagat from comment #2)
> > Regarding this above-mentioned case of two variables (one inside the
> > function), CTF emits debug information for file-scope and global-scope
> > variables only. So in this example, the declaration of a inside the function
> > should not be considered from CTF perspective.
> 
> But a is in the global scope ....
> Just not injected into the global scope for that translation unit.

[I changed the name of variable inside the function to b, as I need some
clarification here.]

static const char a[] = "testme";
void foo () { puts (a); }
int main()
{
  extern const char b[];
  puts (b);
  foo ();
}

In this example, 
-- a is file scope.
-- b is function scope (but external linkage). Correct ?

CTF does not need to identify C type of variable b. But does need to identify C
type of variable a.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Indu Bhagat <ibhagat@gcc.gnu.org>:

https://gcc.gnu.org/g:d0b00e74bf59c73b79471bbe9de19373b8661e20

commit r12-8163-gd0b00e74bf59c73b79471bbe9de19373b8661e20
Author: Indu Bhagat <indu.bhagat@oracle.com>
Date:   Thu Apr 14 10:01:22 2022 -0700

    CTF for extern variable fix [PR105089]

    The CTF format cannot differentiate between a non-defining extern
    variable declaration vs. a defining variable declaration (unlike DWARF).
    So, the correct behaviour wrt the compiler generating CTF for such
    extern variables (i.e., when both the defining and non-defining decl
    are present in the same CU) is to simply emit the CTF variable
    correspoding to the defining declaration.

    To carry out the above, following changes are introduced via the patch:

    1. The CTF container (ctfc.h) now keeps track of the non-defining
declarations
    (by noting the DWARF attribute DW_AT_specification) in a new
ctfc_ignore_vars
    hashtable.  Such book-keeping is necessary because the CTF container should
    not rely on the order of DWARF DIEs presented to it at generation time.

    2. At the time of ctf_add_variable (), the DW_AT_specification DIE if
present
    is added in the ctfc_ignore_vars hashtable.  The CTF variable generation
for
    the defining declaration continues as normal.

    3. If the ctf_add_variable () is asked to generate CTF variable for a DIE
    present in the ctfc_ignore_vars, it skips generating CTF for it.

    4. Recall that CTF variables are pre-processed before emission.  Till now,
the
    only pre-processing that was being done was to sort them in order of their
    names.  Now an additional step is added:  If the CTF variable which
    corresponds to the non-defining declaration is indeed present in the
ctfc_vars
    hashtable (because the corresponding DWARF DIE was encountered first by the
    CTF generation engine), skip that CTF variable from output.

    An important side effect of such a workflow above is that CTF for the C
type
    of the non-defining decl will remain in the CTF dictionary (and will be
    emitted in the output section as well).  This type can be pruned by the
    link-time de-duplicator as usual, if deemed unused.

    2022-04-14  Indu Bhagat  <indu.bhagat@oracle.com>

    gcc/ChangeLog:

            PR debug/105089
            * ctfc.cc (ctf_dvd_ignore_insert): New function.
            (ctf_dvd_ignore_lookup): Likewise.
            (ctf_add_variable): Keep track of non-defining decl DIEs.
            (new_ctf_container): Initialize the new hash-table.
            (ctfc_delete_container): Empty hash-table.
            * ctfc.h (struct ctf_container): Add new hash-table.
            (ctf_dvd_ignore_lookup): New declaration.
            (ctf_add_variable): Add additional argument.
            * ctfout.cc (ctf_dvd_preprocess_cb): Skip adding CTF variable
            record for non-defining decl for which a defining decl exists
            in the same TU.
            (ctf_preprocess): Defer updating the number of global objts
            until here.
            (output_ctf_header): Use ctfc_vars_list_count as some CTF
            variables may not make it to the final output.
            (output_ctf_vars): Likewise.
            * dwarf2ctf.cc (gen_ctf_variable): Skip generating CTF variable
            if this is known to be a non-defining decl DIE.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Indu Bhagat <ibhagat@gcc.gnu.org>:

https://gcc.gnu.org/g:d634c5d7c78c6ec0fa39d96984460475564519c8

commit r12-8164-gd634c5d7c78c6ec0fa39d96984460475564519c8
Author: Indu Bhagat <indu.bhagat@oracle.com>
Date:   Thu Apr 14 10:02:45 2022 -0700

    Refactor and update CTF testcases [PR105089]

    This commit splits the ctf-array-2.c into ctf-array-5.c and
    ctf-variables.c with the following responsibilities:

    [1] ctf-array-2.c: Test CTF generation for unsized arrays.
    [2] ctf-array-5.c: Test CTF generation for unsized but initialized array.
    [3] ctf-variables-3.c: Test CTF generation for extern variable with
defining
    decl.

    Earlier all three tests above were being done in ctf-array-2.c.  The
    checks around [3] were very loose in the original version of ctf-array-2.c
    in that the testcase was only checking that the types are as expected.  The
    compiler was emitting two CTF variable records as follows:

     Variables:
      _CTF_NEWSTR ->  5: const const char [0] (size 0x0) -> 4: const char [0]
(size 0x0)
      _CTF_NEWSTR ->  8: const const char [8] (size 0x8) -> 7: const char [8]
(size 0x8)

    This is incorrect behaviour as it creates ambiguity.  The testcase
    ctf-variables-3.c now has added checks that only one CTF variable record
    is expected.

    2022-04-14  Indu Bhagat  <indu.bhagat@oracle.com>

    gcc/testsuite/ChangeLog:

            PR debug/105089
            * gcc.dg/debug/ctf/ctf-array-2.c: Refactor testcase.  Move some
            checks ...
            * gcc.dg/debug/ctf/ctf-array-5.c: ... to here.
            * gcc.dg/debug/ctf/ctf-variables-3.c: ... and here.  Add
            additional checks for one CTF variable and one CTF object info
            record.

[Bug debug/105089] CTF for a defined extern variable is ambiguous

[ibhagat at gcc dot gnu.org]

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

Indu Bhagat <ibhagat at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
Fixed.