[Bug debug/105089] CTF for a defined extern variable is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 Indu Bhagat changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Indu Bhagat --- Fixed.
[Bug debug/105089] CTF for a defined extern variable is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #7 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:d634c5d7c78c6ec0fa39d96984460475564519c8 commit r12-8164-gd634c5d7c78c6ec0fa39d96984460475564519c8 Author: Indu Bhagat 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #6 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:d0b00e74bf59c73b79471bbe9de19373b8661e20 commit r12-8163-gd0b00e74bf59c73b79471bbe9de19373b8661e20 Author: Indu Bhagat 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
--- Comment #5 from Indu Bhagat ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #4 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #3 from Indu Bhagat --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089 --- Comment #2 from Indu Bhagat --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
--- Comment #1 from Richard Biener ---
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 ();
}
