public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/105089] New: CTF for a defined extern variable is ambiguous
@ 2022-03-28 18:41 ibhagat at gcc dot gnu.org
2022-03-29 7:39 ` [Bug debug/105089] " rguenth at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2022-03-28 18:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
@ 2022-03-29 7:39 ` rguenth at gcc dot gnu.org
2022-03-29 15:58 ` ibhagat at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-03-29 7:39 UTC (permalink / raw)
To: gcc-bugs
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 ();
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
2022-03-29 7:39 ` [Bug debug/105089] " rguenth at gcc dot gnu.org
@ 2022-03-29 15:58 ` ibhagat at gcc dot gnu.org
2022-03-29 16:00 ` ibhagat at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2022-03-29 15:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
2022-03-29 7:39 ` [Bug debug/105089] " rguenth at gcc dot gnu.org
2022-03-29 15:58 ` ibhagat at gcc dot gnu.org
@ 2022-03-29 16:00 ` ibhagat at gcc dot gnu.org
2022-03-29 16:11 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2022-03-29 16:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
` (2 preceding siblings ...)
2022-03-29 16:00 ` ibhagat at gcc dot gnu.org
@ 2022-03-29 16:11 ` pinskia at gcc dot gnu.org
2022-03-29 17:12 ` ibhagat at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-03-29 16:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
` (3 preceding siblings ...)
2022-03-29 16:11 ` pinskia at gcc dot gnu.org
@ 2022-03-29 17:12 ` ibhagat at gcc dot gnu.org
2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2022-03-29 17:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
` (4 preceding siblings ...)
2022-03-29 17:12 ` ibhagat at gcc dot gnu.org
@ 2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
2023-03-16 21:41 ` ibhagat at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-14 17:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
` (5 preceding siblings ...)
2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
@ 2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
2023-03-16 21:41 ` ibhagat at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-14 17:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/105089] CTF for a defined extern variable is ambiguous
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
` (6 preceding siblings ...)
2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
@ 2023-03-16 21:41 ` ibhagat at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2023-03-16 21:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-03-16 21:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-28 18:41 [Bug debug/105089] New: CTF for a defined extern variable is ambiguous ibhagat at gcc dot gnu.org
2022-03-29 7:39 ` [Bug debug/105089] " rguenth at gcc dot gnu.org
2022-03-29 15:58 ` ibhagat at gcc dot gnu.org
2022-03-29 16:00 ` ibhagat at gcc dot gnu.org
2022-03-29 16:11 ` pinskia at gcc dot gnu.org
2022-03-29 17:12 ` ibhagat at gcc dot gnu.org
2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
2022-04-14 17:37 ` cvs-commit at gcc dot gnu.org
2023-03-16 21:41 ` ibhagat 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).