Re: [PATCH 2/2] btf: improve -dA comments for testsuite
On 5/30/23 11:27, David Faust wrote: [Changes from v1: - Fix typos. - Split unrelated change into separate commit. - Improve asm comment for enum constants, update btf-enum-1 test. - Improve asm comment for DATASEC records, update btf-datasec-2 test.] Many BTF type kinds refer to other types via index to the final types list. However, the order of the final types list is not guaranteed to remain the same for the same source program between different runs of the compiler, making it difficult to test inter-type references. This patch updates the assembler comments output when writing a given BTF record to include minimal information about the referenced type, if any. This allows for the regular expressions used in the gcc testsuite to do some basic integrity checks on inter-type references. For example, for the type unsigned int * Assembly comments like the following are written with -dA: .4byte 0 ; TYPE 2 BTF_KIND_PTR '' .4byte 0x200 ; btt_info: kind=2, kflag=0, vlen=0 .4byte 0x1 ; btt_type: (BTF_KIND_INT 'unsigned int') Several BTF tests which can immediately be made more robust with this change are updated. It will also be useful in new tests for the upcoming btf_type_tag support. Re-tested on BPF and x86_64, no known regressions. Thanks. LGTM. Thanks gcc/ * btfout.cc (btf_kind_names): New. (btf_kind_name): New. (btf_absolute_var_id): New utility function. (btf_relative_var_id): Likewise. (btf_relative_func_id): Likewise. (btf_absolute_datasec_id): Likewise. (btf_asm_type_ref): New. (btf_asm_type): Update asm comments and use btf_asm_type_ref (). (btf_asm_array): Likewise. Accept ctf_container_ref parameter. (btf_asm_varent): Likewise. (btf_asm_func_arg): Likewise. (btf_asm_datasec_entry): Likewise. (btf_asm_datasec_type): Likewise. (btf_asm_func_type): Likewise. Add index parameter. (btf_asm_enum_const): Likewise. (btf_asm_sou_member): Likewise. (output_btf_vars): Update btf_asm_* call accordingly. (output_asm_btf_sou_fields): Likewise. (output_asm_btf_enum_list): Likewise. (output_asm_btf_func_args_list): Likewise. (output_asm_btf_vlen_bytes): Likewise. (output_btf_func_types): Add ctf_container_ref parameter. Pass it to btf_asm_func_type. (output_btf_datasec_types): Update btf_asm_datsec_type call similarly. (btf_output): Update output_btf_func_types call similarly. gcc/testsuite/ * gcc.dg/debug/btf/btf-array-1.c: Use new BTF asm comments in scan-assembler expressions where useful. * gcc.dg/debug/btf/btf-anonymous-struct-1.c: Likewise. * gcc.dg/debug/btf/btf-anonymous-union-1.c: Likewise. * gcc.dg/debug/btf/btf-bitfields-2.c: Likewise. * gcc.dg/debug/btf/btf-bitfields-3.c: Likewise. * gcc.dg/debug/btf/btf-datasec-2.c: Likewise. * gcc.dg/debug/btf/btf-enum-1.c: Likewise. * gcc.dg/debug/btf/btf-function-6.c: Likewise. * gcc.dg/debug/btf/btf-pointers-1.c: Likewise. * gcc.dg/debug/btf/btf-struct-1.c: Likewise. * gcc.dg/debug/btf/btf-struct-2.c: Likewise. * gcc.dg/debug/btf/btf-typedef-1.c: Likewise. * gcc.dg/debug/btf/btf-union-1.c: Likewise. * gcc.dg/debug/btf/btf-variables-1.c: Likewise. * gcc.dg/debug/btf/btf-variables-2.c: Likewise. Update outdated comment. * gcc.dg/debug/btf/btf-function-3.c: Update outdated comment. --- gcc/btfout.cc | 227 ++ .../gcc.dg/debug/btf/btf-anonymous-struct-1.c | 3 +- .../gcc.dg/debug/btf/btf-anonymous-union-1.c | 4 +- gcc/testsuite/gcc.dg/debug/btf/btf-array-1.c | 3 + .../gcc.dg/debug/btf/btf-bitfields-2.c| 2 +- .../gcc.dg/debug/btf/btf-bitfields-3.c| 2 +- .../gcc.dg/debug/btf/btf-datasec-2.c | 4 +- gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c | 4 + .../gcc.dg/debug/btf/btf-function-3.c | 2 +- .../gcc.dg/debug/btf/btf-function-6.c | 4 +- .../gcc.dg/debug/btf/btf-pointers-1.c | 3 + gcc/testsuite/gcc.dg/debug/btf/btf-struct-1.c | 4 +- gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c | 2 +- .../gcc.dg/debug/btf/btf-typedef-1.c | 14 +- gcc/testsuite/gcc.dg/debug/btf/btf-union-1.c | 2 +- .../gcc.dg/debug/btf/btf-variables-1.c| 6 + .../gcc.dg/debug/btf/btf-variables-2.c| 7 +- 17 files changed, 224 insertions(+), 69 deletions(-) diff --git a/gcc/btfout.cc b/gcc/btfout.cc index ae9855716eb..f51ccf73242 100644 --- a/gcc/btfout.cc +++ b/gcc/btfout.cc @@ -114,6 +114,23 @@ static unsigned int num_types_added = 0; CTF types. */ static unsigned int num_types_created = 0; +/* Name strings for BTF kinds. + Note: the indices here must match the type defines in btf.h. */ +static
Re: [PATCH 1/2] btf: be clear when record size/type is not used
On 5/30/23 11:27, David Faust wrote: [Changes from v1: split this change into own commit.] All BTF type records have a 4-byte field used to encode a size or link to another type, depending on the type kind. But BTF_KIND_ARRAY and BTF_KIND_FWD do not use this field at all, and should write zero. GCC already correctly writes zero in this field for these type kinds, but the process is not straightforward and results in the -dA comment claiming the field is a reference to another type. This patch makes the behavior explicit and updates the assembler comment to state clearly that the field is unused. LGTM. Thanks gcc/ * btfout.cc (btf_asm_type): Add dedicated cases for BTF_KIND_ARRAY and BTF_KIND_FWD which do not use the size/type field at all. --- gcc/btfout.cc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/gcc/btfout.cc b/gcc/btfout.cc index 497c1ca06e6..ae9855716eb 100644 --- a/gcc/btfout.cc +++ b/gcc/btfout.cc @@ -705,6 +705,12 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd) dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB", dtd->dtd_data.ctti_size); return; +case BTF_KIND_ARRAY: +case BTF_KIND_FWD: + /* These types do not encode any information in the size/type field +and should write 0. */ + dw2_asm_output_data (4, 0, "(unused)"); + return; default: break; }
Re: [PATCH] btf: improve -dA comments for testsuite
On 5/30/23 09:08, David Faust wrote:
@@ -793,7 +917,8 @@ btf_asm_enum_const (unsigned int size, ctf_dmdef_t * dmd)
/* Asm'out a function parameter description following a BTF_KIND_FUNC_PROTO.
*/
static void
-btf_asm_func_arg (ctf_func_arg_t * farg, size_t stroffset)
+btf_asm_func_arg (ctf_container_ref ctfc, ctf_func_arg_t * farg,
+ size_t stroffset)
{
/* If the function arg does not have a name, refer to the null string at
the start of the string table. This ensures correct encoding for varargs
@@ -803,31 +928,33 @@ btf_asm_func_arg (ctf_func_arg_t * farg, size_t stroffset)
else
dw2_asm_output_data (4, 0, "farg_name");
- dw2_asm_output_data (4, (btf_removed_type_p (farg->farg_type)
- ? BTF_VOID_TYPEID
- : get_btf_id (farg->farg_type)),
- "farg_type");
+ btf_asm_type_ref ("farg_type", ctfc, (btf_removed_type_p (farg->farg_type)
+ ? BTF_VOID_TYPEID
+ : get_btf_id (farg->farg_type)));
}
/* Asm'out a BTF_KIND_FUNC type. */
Lets keep the function level comments updated. Apart from
btf_asm_func_type, this comment applies to other functions touched in
this commit, like btf_asm_datasec_type.
I don't follow. All those functions are still doing the same thing.
What needs to be updated exactly?
I meant updating the function-level comments for the additional args
that are added.
I saw that in this patch, the new functions added follow the style of
explaining the args, like,
+/* Return the relative index of the variable with final BTF ID ABS. */
+
+static ctf_id_t
+btf_relative_var_id (ctf_id_t abs)
Hence, my comment. But on second look, however, I see that the file
keeps a mix of different styles. This one is up to you then. It makes
sense to leave out the self-explanatory args.
static void
-btf_asm_func_type (ctf_dtdef_ref dtd)
+btf_asm_func_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd, size_t i)
{
- dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
- dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
- dtd->linkage),
- "btt_info: kind=%u, kflag=%u, linkage=%u",
- BTF_KIND_FUNC, 0, dtd->linkage);
- dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
+ ctf_id_t ref_id = dtd->dtd_data.ctti_type;
+ dw2_asm_output_data (4, dtd->dtd_data.ctti_name,
+ "TYPE %lu BTF_KIND_FUNC '%s'",
+ num_types_added + num_vars_added + 1 + i,
+ dtd->dtd_name);
+ dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, dtd->linkage),
+ "btt_info: kind=%u, kflag=%u, linkage=%u",
+ BTF_KIND_FUNC, 0, dtd->linkage);
+ btf_asm_type_ref ("btt_type", ctfc, get_btf_id (ref_id));
}
/* Asm'out a variable entry following a BTF_KIND_DATASEC. */
static void
-btf_asm_datasec_entry (struct btf_var_secinfo info)
+btf_asm_datasec_entry (ctf_container_ref ctfc, struct btf_var_secinfo info)
{
- dw2_asm_output_data (4, info.type, "bts_type");
+ btf_asm_type_ref ("bts_type", ctfc, info.type);
dw2_asm_output_data (4, info.offset, "bts_offset");
dw2_asm_output_data (4, info.size, "bts_size");
}
@@ -835,9 +962,12 @@ btf_asm_datasec_entry (struct btf_var_secinfo info)
/* Asm'out a whole BTF_KIND_DATASEC, including its variable entries. */
static void
-btf_asm_datasec_type (btf_datasec_t ds, size_t stroffset)
+btf_asm_datasec_type (ctf_container_ref ctfc, btf_datasec_t ds, ctf_id_t id,
+ size_t stroffset)
{
- dw2_asm_output_data (4, ds.name_offset + stroffset, "btt_name");
+ dw2_asm_output_data (4, ds.name_offset + stroffset,
+ "TYPE %lu BTF_KIND_DATASEC '%s'",
+ btf_absolute_datasec_id (id), ds.name);
dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_DATASEC, 0,
ds.entries.length ()),
"btt_info");
@@ -845,7 +975,7 @@ btf_asm_datasec_type (btf_datasec_t ds, size_t stroffset)
loaders such as libbpf. */
dw2_asm_output_data (4, 0, "btt_size");
for (size_t i = 0; i < ds.entries.length (); i++)
-btf_asm_datasec_entry (ds.entries[i]);
+btf_asm_datasec_entry (ctfc, ds.entries[i]);
}
Re: [PATCH] btf: improve -dA comments for testsuite
On 5/25/23 9:37 AM, David Faust via Gcc-patches wrote:
Many BTF type kinds refer to other types via index to the final types
list. However, the order of the final types list is not guaranteed to
remain the same for the same source program between different runs of
the compiler, making it difficult to test inter-type references.
This patch updates the assembler comments output when writing a
given BTF record to include minimal information about the referenced
type, if any. This allows for the regular expressions used in the gcc
testsuite to do some basic integrity checks on inter-type references.
For example, for the type
unsigned int *
Assembly comments like the following are written with -dA:
.4byte 0 ; TYPE 2 BTF_KIND_PTR ''
.4byte 0x200 ; btt_info: kind=2, kflag=0, vlen=0
.4byte 0x1 ; btt_type: (BTF_KIND_INT 'unsigned int')
Several BTF tests which can immediately be made more robust with this
change are updated. It will also be useful in new tests for the upcoming
btf_type_tag support.
Thanks for working on this, David. It will be nice to use these
enhanced assembler comments in the output for some of CTF testing as
well sometime. But we can get to that later after this comit.
Some comments inlined below.
Tested on BPF and x86_64, no known regressions.
OK for trunk?
Thanks.
gcc/
* btfout.cc (btf_kind_names): New.
(btf_kind_name): New.
(btf_absolute_var_id): New utility function.
(btf_relative_var_id): Likewise.
(btf_relative_func_id): Likewise.
(btf_absolute_datasec_id): Likewise.
(btf_asm_type_ref): New.
(btf_asm_type): Update asm comments and use btf_asm_type_ref ().
(btf_asm_array): Likewise. Accept ctf_container_ref parameter.
(btf_asm_varent): Likewise.
(btf_asm_func_arg): Likewise.
(btf_asm_datasec_entry): Likewise.
(btf_asm_datasec_type): Likewise.
(btf_asm_func_type): Likewise. Add index parameter.
(btf_asm_sou_member): Likewise.
(output_btf_vars): Update btf_asm_* call accordingly.
(output_asm_btf_sou_fields): Likewise.
(output_asm_btf_func_args_list): Likewise.
(output_asm_btf_vlen_bytes): Likewise.
(output_btf_func_types): Add ctf_container_ref parameter.
Pass it to btf_asm_func_type.
(output_btf_datasec_types): Update btf_asm_datsec_type call similarly.
(btf_output): Update output_btf_func_types call similarly.
gcc/testsuite/
* gcc.dg/debug/btf/btf-array-1.c: Use new BTF asm comments
in scan-assembler expressions where useful.
* gcc.dg/debug/btf/btf-anonymous-struct-1.c: Likewise.
* gcc.dg/debug/btf/btf-anonymous-union-1.c: Likewise.
* gcc.dg/debug/btf/btf-bitfields-2.c: Likewise.
* gcc.dg/debug/btf/btf-bitfields-3.c: Likewise.
* gcc.dg/debug/btf/btf-function-6.c: Likewise.
* gcc.dg/debug/btf/btf-pointers-1.c: Likewise.
* gcc.dg/debug/btf/btf-struct-1.c: Likewise.
* gcc.dg/debug/btf/btf-struct-2.c: Likewise.
* gcc.dg/debug/btf/btf-typedef-1.c: Likewise.
* gcc.dg/debug/btf/btf-union-1.c: Likewise.
* gcc.dg/debug/btf/btf-variables-1.c: Likewise.
* gcc.dg/debug/btf/btf-variables-2.c: Likewise. Update outdated comment.
* gcc.dg/debug/btf/btf-function-3.c: Update outdated comment.
---
gcc/btfout.cc | 220 ++
.../gcc.dg/debug/btf/btf-anonymous-struct-1.c | 3 +-
.../gcc.dg/debug/btf/btf-anonymous-union-1.c | 4 +-
gcc/testsuite/gcc.dg/debug/btf/btf-array-1.c | 3 +
.../gcc.dg/debug/btf/btf-bitfields-2.c| 2 +-
.../gcc.dg/debug/btf/btf-bitfields-3.c| 2 +-
.../gcc.dg/debug/btf/btf-function-3.c | 2 +-
.../gcc.dg/debug/btf/btf-function-6.c | 4 +-
.../gcc.dg/debug/btf/btf-pointers-1.c | 3 +
gcc/testsuite/gcc.dg/debug/btf/btf-struct-1.c | 4 +-
gcc/testsuite/gcc.dg/debug/btf/btf-struct-2.c | 2 +-
.../gcc.dg/debug/btf/btf-typedef-1.c | 14 +-
gcc/testsuite/gcc.dg/debug/btf/btf-union-1.c | 2 +-
.../gcc.dg/debug/btf/btf-variables-1.c| 6 +
.../gcc.dg/debug/btf/btf-variables-2.c| 7 +-
15 files changed, 215 insertions(+), 63 deletions(-)
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 497c1ca06e6..8960acfbbaa 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -114,6 +114,23 @@ static unsigned int num_types_added = 0;
CTF types. */
static unsigned int num_types_created = 0;
+/* Name strings for BTF kinds.
+ Note: the indices here must match the type defines in btf.h. */
+static const char *const btf_kind_names[] =
+ {
+"UNKN", "INT", "PTR", "ARRAY", "STRUCT", "UNION", "ENUM", "FWD",
+"TYPEDEF", "VOLATILE", "CONST", "RESTRICT", "FUNC", "FUNC_PROTO",
+"VAR", "DATASEC", "FLOAT", "DECL_TAG", "TYPE_TAG", "ENUM64"
+ };
+
+/* Return a name string
[Committed] MAINTAINERS: Add myself as CTF and BTF reviewer
Looks like I did this only in my head back then. Finally pushed. Thanks! ChangeLog: * MAINTAINERS: Add myself. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c8045d49861..cebf45d49e5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -271,6 +271,7 @@ check in changes outside of the parts of the compiler they maintain. arc port Claudiu Zissulescu callgraph Martin Jambor C front endMarek Polacek +CTF, BTF Indu Bhagat CTF, BTF David Faust dataflow Paolo Bonzini dataflow Seongbae Park @@ -340,7 +341,6 @@ Andrew Benson Daniel Berlin Pat Bernardi Jan Beulich -Indu Bhagat David Billinghurst Tomas Bily Laurynas Biveinis -- 2.39.2
Re: [PATCH v2 0/3] btf: fix BTF for extern items [PR106773]
On 12/13/22 10:44, David Faust wrote: [Changes from v1: - Remove #defines for LINKAGE_* values, instead mirror enums from linux/btf.h to include/btf.h and use those. - Fix BTF generation for extern variable with both non-defining and defining decls in the same CU. Add a test for this. - Update several comments per review feedback. ] Hi, This series fixes the issues reported in target/PR106773. I decided to split it into three commits, as there are ultimately three distinct issues and fixes. See each patch for details. Tested on bpf-unknown-none and x86_64-linux-gnu, no known regressions. OK to push? Thanks. Hi David, LGTM. Thanks David Faust (3): btf: add 'extern' linkage for variables [PR106773] btf: fix 'extern const void' variables [PR106773] btf: correct generation for extern funcs [PR106773] gcc/btfout.cc | 184 +- .../gcc.dg/debug/btf/btf-datasec-2.c | 28 +++ .../gcc.dg/debug/btf/btf-function-6.c | 19 ++ gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 25 +++ .../gcc.dg/debug/btf/btf-variables-4.c| 24 +++ .../gcc.dg/debug/btf/btf-variables-5.c| 19 ++ include/btf.h | 29 ++- 7 files changed, 276 insertions(+), 52 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-6.c create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-5.c
Re: [PATCH 1/3] btf: add 'extern' linkage for variables [PR106773]
On 12/12/22 12:47, David Faust wrote:
On 12/8/22 22:55, Indu Bhagat wrote:
Hi David,
On 12/7/22 12:57, David Faust wrote:
Add support for the 'extern' linkage value for BTF_KIND_VAR records,
which is used for variables declared as extern in the source file.
PR target/106773
gcc/
* btfout.cc (BTF_LINKAGE_STATIC): New define.
(BTF_LINKAGE_GLOBAL): Likewise.
(BTF_LINKAGE_EXTERN): Likewise.
(btf_collect_datasec): Mark extern variables as such.
(btf_asm_varent): Accomodate 'extern' linkage.
gcc/testsuite/
* gcc.dg/debug/btf/btf-variables-4.c: New test.
include/
* btf.h (struct btf_var): Update comment to note 'extern' linkage.
---
gcc/btfout.cc | 9 ++-
.../gcc.dg/debug/btf/btf-variables-4.c| 24 +++
include/btf.h | 2 +-
3 files changed, 33 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index aef9fd70a28..a1c6266a7db 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -66,6 +66,10 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES];
#define BTF_INVALID_TYPEID 0x
+#define BTF_LINKAGE_STATIC 0
+#define BTF_LINKAGE_GLOBAL 1
+#define BTF_LINKAGE_EXTERN 2
+
I was about to suggest to rename these to use the same name as used in
the kernel btf.h. What is used there is:
BTF_VAR_STATIC = 0,
BTF_VAR_GLOBAL_ALLOCATED = 1,
BTF_VAR_GLOBAL_EXTERN = 2,
But after looking at the Patch 3/3, I see you reuse these definitions
for functions as well. I just find the names confusing on the first look
- "BTF_LINKAGE_STATIC".
Naming aside, what do you think about adding the defines to
include/btf.h instead ?
Actually, I forgot these are defined (separately for both VARs and FUNCs)
in the kernel uapi/linux/btf.h. It would probably be best to mirror that
approach and use a separate enum for each, in include/btf.h. WDYT?
Yes, mirroring in include/btf.h sounds good.
/* Mapping of CTF variables to the IDs they will be assigned when they are
converted to BTF_KIND_VAR type records. Strictly accounts for the index
from the start of the variable type entries, does not include the number
@@ -314,6 +318,9 @@ btf_collect_datasec (ctf_container_ref ctfc)
continue;
const char *section_name = node->get_section ();
+ /* Mark extern variables. */
+ if (DECL_EXTERNAL (node->decl))
+ dvd->dvd_visibility = BTF_LINKAGE_EXTERN;
This made me think about the following case.
extern const char a[];
const char a[] = "foo";
What is the expected BTF for this? Since BTF can differentiate between
the non-defining extern variable declaration, I expected to see two
variables with different "linkage". At this time I see, two variables
with global linkage but different types:
.long 0xe00 # btv_info
.long 0x4 # btv_type
.long 0x1 # btv_linkage
.long 0x1f# btv_name
.long 0xe00 # btv_info
.long 0x7 # btv_type
.long 0x1 # btv_linkage
.long 0x60# btt_name
The BTF documentation in the kernel does not clarify this case.
Going off the implementation in clang as a reference, it looks like
only one VAR record is expected, with 'global' linkage:
$ cat extdef.c
extern const char a[];
const char a[] = "foo";
$ clang -target bpf -c -g extdef.c -o extdef.o
$ /usr/sbin/bpftool btf dump file extdef.o
[1] CONST '(anon)' type_id=2
[2] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[3] ARRAY '(anon)' type_id=1 index_type_id=4 nr_elems=4
[4] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
[5] VAR 'a' type_id=3, linkage=global
[6] DATASEC '.rodata' size=0 vlen=1
type_id=5 offset=0 size=4 (VAR 'a')
In GCC we have two records since we have two DIEs for "a" in the
DWARF. One has type "const char[4]" and the other has type
"const char[]", so the BTF records point to two different types
as well.
I guess we should find a way in BTF to identify this and
emit only the defining definition as clang does.
CTF had a similar issue earlier. See PR105089.
https://gcc.gnu.org/PR105089
if (section_name == NULL)
{
@@ -676,7 +683,7 @@ btf_asm_varent (ctf_dvdef_ref var)
dw2_asm_output_data (4, var->dvd_name_offset, "btv_name");
dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_VAR, 0, 0), "btv_info");
dw2_asm_output_data (4, get_btf_id (var->dvd_type), "btv_type");
- dw2_asm_output_data (4, (var->dvd_visibility ? 1 : 0), "btv_linkage");
+ dw2_asm_output_data (4, var->dvd_visibility, "btv_linkage");
}
/* Asm'out a member description following a BTF_KIND_STRUCT or
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-
Re: [PATCH 3/3] btf: correct generation for extern funcs [PR106773]
On 12/12/22 12:31, David Faust wrote:
On 12/8/22 23:36, Indu Bhagat wrote:
On 12/7/22 12:57, David Faust wrote:
The eBPF loader expects to find entries for functions declared as extern
in the corresponding BTF_KIND_DATASEC record, but we were not generating
these entries.
This patch adds support for the 'extern' linkage of function types in
BTF, and creates entries for for them BTF_KIND_DATASEC records as needed.
PR target/106773
gcc/
* btfout.cc (get_section_name): New function.
(btf_collect_datasec): Use it here. Process functions, marking them
'extern' and generating DATASEC entries for them as appropriate. Move
creation of BTF_KIND_FUNC records to here...
(btf_dtd_emit_preprocess_cb): ... from here.
gcc/testsuite/
* gcc.dg/debug/btf/btf-datasec-2.c: New test.
* gcc.dg/debug/btf/btf-function-6.c: New test.
include/
* btf.h (struct btf_var_secinfo): Update comments with notes about
extern functions.
---
gcc/btfout.cc | 129 --
.../gcc.dg/debug/btf/btf-datasec-2.c | 28
.../gcc.dg/debug/btf/btf-function-6.c | 19 +++
include/btf.h | 9 +-
4 files changed, 139 insertions(+), 46 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-6.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 05f3a3f9b6e..d7ead377ec5 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -294,7 +294,35 @@ btf_datasec_push_entry (ctf_container_ref ctfc, const char
*secname,
ds.entries.safe_push (info);
datasecs.safe_push (ds);
- num_types_created++;
+}
+
+
+/* Return the section name, as of interest to btf_collect_datasec, for the
+ given symtab node. Note that this deliberately returns NULL for objects
+ which do not go in a section btf_collect_datasec cares about. */
"Dot, space, space, new sentence."
+static const char *
+get_section_name (symtab_node *node)
+{
+ const char *section_name = node->get_section ();
+
+ if (section_name == NULL)
+{
+ switch (categorize_decl_for_section (node->decl, 0))
+ {
+ case SECCAT_BSS:
+ section_name = ".bss";
+ break;
+ case SECCAT_DATA:
+ section_name = ".data";
+ break;
+ case SECCAT_RODATA:
+ section_name = ".rodata";
+ break;
+ default:;
+ }
+}
+
+ return section_name;
}
/* Construct all BTF_KIND_DATASEC records for CTFC. One such record is created
@@ -305,7 +333,60 @@ btf_datasec_push_entry (ctf_container_ref ctfc, const char
*secname,
static void
btf_collect_datasec (ctf_container_ref ctfc)
{
- /* See cgraph.h struct symtab_node, which varpool_node extends. */
+ cgraph_node *func;
+ FOR_EACH_FUNCTION (func)
+{
+ dw_die_ref die = lookup_decl_die (func->decl);
+ if (die == NULL)
+ continue;
+
+ ctf_dtdef_ref dtd = ctf_dtd_lookup (ctfc, die);
+ if (dtd == NULL)
+ continue;
+
+ /* Functions actually get two types: a BTF_KIND_FUNC_PROTO, and
+also a BTF_KIND_FUNC. But the CTF container only allocates one
+type per function, which matches closely with BTF_KIND_FUNC_PROTO.
+For each such function, also allocate a BTF_KIND_FUNC entry.
+These will be output later. */
"Dot, space, space, new sentence."
+ ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
+ func_dtd->dtd_data = dtd->dtd_data;
+ func_dtd->dtd_data.ctti_type = dtd->dtd_type;
+ func_dtd->linkage = dtd->linkage;
+ func_dtd->dtd_type = num_types_added + num_types_created;
+
+ /* Only the BTF_KIND_FUNC type actually references the name. The
+BTF_KIND_FUNC_PROTO is always anonymous. */
+ dtd->dtd_data.ctti_name = 0;
+
+ vec_safe_push (funcs, func_dtd);
+ num_types_created++;
+
+ /* Mark any 'extern' funcs and add DATASEC entries for them. */
+ if (DECL_EXTERNAL (func->decl))
+ {
+ func_dtd->linkage = BTF_LINKAGE_EXTERN;
+
What is the expected BTF when both decl and definition are present:
extern int extfunc(int x);
int extfunc (int x) {
int y = foo ();
return y;
}
Using clang implementation as the reference, a single FUNC record
for "extfunc" with "global" linkage:
$ cat extfuncdef.c
extern int extfunc (int x);
int extfunc (int x) {
int y = foo ();
return y;
}
$ clang -target bpf -c -g extfuncdef.c -o extfuncdef.o
$ /usr/sbin/bpftool btf dump file extfuncdef.o
[1] FUNC_PROTO '(anon)' ret_type_id=2 vlen=1
'(anon)' type_id=2
[2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[3] FUNC 'extfunc' type_id=1 linkage=global
With this patch we do the same in GCC.
OK. Thanks for confirming.
+ const char *section_name = get_section_name (func);
+ /* Note: get_section_name () returns NULL for fu
Re: [PATCH 2/3] btf: fix 'extern const void' variables [PR106773]
On 12/12/22 12:59, David Faust wrote:
On 12/8/22 23:34, Indu Bhagat wrote:
Looks OK to me overall. Minor comments below.
Thanks
On 12/7/22 12:57, David Faust wrote:
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
In addition, the internal DWARF representation from which BTF is
produced does not generate 'const' modifier DIEs for the void type,
which meant in BTF the 'const' qualifier was dropped for 'extern const
void' variables. This patch also adds support for generating a const
void type in BTF to correct emission for these variables.
PR target/106773
gcc/
* btfout.cc (btf_collect_datasec): Correct size of void entries.
(btf_dvd_emit_preprocess_cb): Do not skip emitting variables which
refer to void types.
(btf_init_postprocess): Create 'const void' type record if needed and
adjust variables to refer to it as appropriate.
gcc/testsuite/
* gcc.dg/debug/btf/btf-pr106773.c: New test.
---
gcc/btfout.cc | 44 +--
gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 25 +++
2 files changed, 65 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index a1c6266a7db..05f3a3f9b6e 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -354,6 +354,8 @@ btf_collect_datasec (ctf_container_ref ctfc)
tree size = DECL_SIZE_UNIT (node->decl);
if (tree_fits_uhwi_p (size))
info.size = tree_to_uhwi (size);
+ else if (VOID_TYPE_P (TREE_TYPE (node->decl)))
+ info.size = 1;
/* Offset is left as 0 at compile time, to be filled in by loaders such
as libbpf. */
@@ -439,7 +441,7 @@ btf_dvd_emit_preprocess_cb (ctf_dvdef_ref *slot,
ctf_container_ref arg_ctfc)
ctf_dvdef_ref var = (ctf_dvdef_ref) * slot;
/* Do not add variables which refer to unsupported types. */
- if (btf_removed_type_p (var->dvd_type))
+ if (!voids.contains (var->dvd_type) && btf_removed_type_p (var->dvd_type))
return 1;
arg_ctfc->ctfc_vars_list[num_vars_added] = var;
@@ -1073,15 +1075,49 @@ btf_init_postprocess (void)
{
ctf_container_ref tu_ctfc = ctf_get_tu_ctfc ();
- size_t i;
- size_t num_ctf_types = tu_ctfc->ctfc_types->elements ();
-
holes.create (0);
voids.create (0);
num_types_added = 0;
num_types_created = 0;
+ /* Workaround for 'const void' variables. These variables are sometimes used
+ in eBPF programs to address kernel symbols. DWARF does not generate const
+ qualifier on void type, so we would incorrectly emit these variables
+ without the const qualifier.
+ Unfortunately we need the TREE node to know it was const, and we need
+ to create the const modifier type (if needed) now, before making the types
+ list. So we can't avoid iterating with FOR_EACH_VARIABLE here, and then
+ again when creating the DATASEC entries. */
"Dot, space, space, new sentence." in 3 places.
+ ctf_id_t constvoid_id = CTF_NULL_TYPEID;
+ varpool_node *var;
+ FOR_EACH_VARIABLE (var)
+{
+ if (!var->decl)
+ continue;
+
+ tree type = TREE_TYPE (var->decl);
+ if (type && VOID_TYPE_P (type) && TYPE_READONLY (type))
+ {
+ dw_die_ref die = lookup_decl_die (var->decl);
+ if (die == NULL)
+ continue;
+
+ ctf_dvdef_ref dvd = ctf_dvd_lookup (tu_ctfc, die);
+ if (dvd == NULL)
+ continue;
+
+ /* Create the 'const' modifier type for void. */
+ if (constvoid_id == CTF_NULL_TYPEID)
+ constvoid_id = ctf_add_reftype (tu_ctfc, CTF_ADD_ROOT,
+ dvd->dvd_type, CTF_K_CONST, NULL);
No de-duplication of the const void type. I assume libbpf will take
care of this eventually.
Hm, not sure I follow. Where is the duplication? The const void type is
only created once here, for the first such variable which needs it, and
reused for subsequent variables. And it does not already exist in the
CTF which we are translating into BTF.
You're right - you are reusing the const void type once generated for a
CU for each usage. My bad - I didnt follow the code properly :)
In any case, yes libbpf can handle duplicated types. Though it would
still be good to minimize that where we can to not bloat the BTF info.
+ dvd->dvd_type = constvoid_id;
+ }
+}
+
+ size_t i;
+ size_t num_ctf_types = tu_ctfc->ctfc_types->elements ();
+
if (num_ctf_types)
{
init_btf_id_map (num_ctf_types + 1);
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
new file mode 100644
index 000..f90fa773a4b
--- /dev/null
+++ b/gcc/testsuite/g
Re: [PATCH 3/3] btf: correct generation for extern funcs [PR106773]
On 12/7/22 12:57, David Faust wrote:
The eBPF loader expects to find entries for functions declared as extern
in the corresponding BTF_KIND_DATASEC record, but we were not generating
these entries.
This patch adds support for the 'extern' linkage of function types in
BTF, and creates entries for for them BTF_KIND_DATASEC records as needed.
PR target/106773
gcc/
* btfout.cc (get_section_name): New function.
(btf_collect_datasec): Use it here. Process functions, marking them
'extern' and generating DATASEC entries for them as appropriate. Move
creation of BTF_KIND_FUNC records to here...
(btf_dtd_emit_preprocess_cb): ... from here.
gcc/testsuite/
* gcc.dg/debug/btf/btf-datasec-2.c: New test.
* gcc.dg/debug/btf/btf-function-6.c: New test.
include/
* btf.h (struct btf_var_secinfo): Update comments with notes about
extern functions.
---
gcc/btfout.cc | 129 --
.../gcc.dg/debug/btf/btf-datasec-2.c | 28
.../gcc.dg/debug/btf/btf-function-6.c | 19 +++
include/btf.h | 9 +-
4 files changed, 139 insertions(+), 46 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-6.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 05f3a3f9b6e..d7ead377ec5 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -294,7 +294,35 @@ btf_datasec_push_entry (ctf_container_ref ctfc, const char
*secname,
ds.entries.safe_push (info);
datasecs.safe_push (ds);
- num_types_created++;
+}
+
+
+/* Return the section name, as of interest to btf_collect_datasec, for the
+ given symtab node. Note that this deliberately returns NULL for objects
+ which do not go in a section btf_collect_datasec cares about. */
"Dot, space, space, new sentence."
+static const char *
+get_section_name (symtab_node *node)
+{
+ const char *section_name = node->get_section ();
+
+ if (section_name == NULL)
+{
+ switch (categorize_decl_for_section (node->decl, 0))
+ {
+ case SECCAT_BSS:
+ section_name = ".bss";
+ break;
+ case SECCAT_DATA:
+ section_name = ".data";
+ break;
+ case SECCAT_RODATA:
+ section_name = ".rodata";
+ break;
+ default:;
+ }
+}
+
+ return section_name;
}
/* Construct all BTF_KIND_DATASEC records for CTFC. One such record is created
@@ -305,7 +333,60 @@ btf_datasec_push_entry (ctf_container_ref ctfc, const char
*secname,
static void
btf_collect_datasec (ctf_container_ref ctfc)
{
- /* See cgraph.h struct symtab_node, which varpool_node extends. */
+ cgraph_node *func;
+ FOR_EACH_FUNCTION (func)
+{
+ dw_die_ref die = lookup_decl_die (func->decl);
+ if (die == NULL)
+ continue;
+
+ ctf_dtdef_ref dtd = ctf_dtd_lookup (ctfc, die);
+ if (dtd == NULL)
+ continue;
+
+ /* Functions actually get two types: a BTF_KIND_FUNC_PROTO, and
+also a BTF_KIND_FUNC. But the CTF container only allocates one
+type per function, which matches closely with BTF_KIND_FUNC_PROTO.
+For each such function, also allocate a BTF_KIND_FUNC entry.
+These will be output later. */
"Dot, space, space, new sentence."
+ ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
+ func_dtd->dtd_data = dtd->dtd_data;
+ func_dtd->dtd_data.ctti_type = dtd->dtd_type;
+ func_dtd->linkage = dtd->linkage;
+ func_dtd->dtd_type = num_types_added + num_types_created;
+
+ /* Only the BTF_KIND_FUNC type actually references the name. The
+BTF_KIND_FUNC_PROTO is always anonymous. */
+ dtd->dtd_data.ctti_name = 0;
+
+ vec_safe_push (funcs, func_dtd);
+ num_types_created++;
+
+ /* Mark any 'extern' funcs and add DATASEC entries for them. */
+ if (DECL_EXTERNAL (func->decl))
+ {
+ func_dtd->linkage = BTF_LINKAGE_EXTERN;
+
What is the expected BTF when both decl and definition are present:
extern int extfunc(int x);
int extfunc (int x) {
int y = foo ();
return y;
}
+ const char *section_name = get_section_name (func);
+ /* Note: get_section_name () returns NULL for functions in text
+section. This is intentional, since we do not want to generate
+DATASEC entries for them. */
"Dot, space, space, new sentence."
+ if (section_name == NULL)
+ continue;
+
+ struct btf_var_secinfo info;
+
+ /* +1 for the sentinel type not in the types map. */
+ info.type = func_dtd->dtd_type + 1;
+
+ /* Both zero at compile time. */
+ info.size = 0;
+ info.offset = 0;
+
+ btf_datasec_push_entry (ctfc, section_name, info);
+ }
+}
+
varpool_node *node;
FOR_EACH_VARIABLE (node)
{
@@ -317,28 +398,13 @@ btf_collect_da
Re: [PATCH 2/3] btf: fix 'extern const void' variables [PR106773]
Looks OK to me overall. Minor comments below.
Thanks
On 12/7/22 12:57, David Faust wrote:
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
In addition, the internal DWARF representation from which BTF is
produced does not generate 'const' modifier DIEs for the void type,
which meant in BTF the 'const' qualifier was dropped for 'extern const
void' variables. This patch also adds support for generating a const
void type in BTF to correct emission for these variables.
PR target/106773
gcc/
* btfout.cc (btf_collect_datasec): Correct size of void entries.
(btf_dvd_emit_preprocess_cb): Do not skip emitting variables which
refer to void types.
(btf_init_postprocess): Create 'const void' type record if needed and
adjust variables to refer to it as appropriate.
gcc/testsuite/
* gcc.dg/debug/btf/btf-pr106773.c: New test.
---
gcc/btfout.cc | 44 +--
gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 25 +++
2 files changed, 65 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index a1c6266a7db..05f3a3f9b6e 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -354,6 +354,8 @@ btf_collect_datasec (ctf_container_ref ctfc)
tree size = DECL_SIZE_UNIT (node->decl);
if (tree_fits_uhwi_p (size))
info.size = tree_to_uhwi (size);
+ else if (VOID_TYPE_P (TREE_TYPE (node->decl)))
+ info.size = 1;
/* Offset is left as 0 at compile time, to be filled in by loaders such
as libbpf. */
@@ -439,7 +441,7 @@ btf_dvd_emit_preprocess_cb (ctf_dvdef_ref *slot,
ctf_container_ref arg_ctfc)
ctf_dvdef_ref var = (ctf_dvdef_ref) * slot;
/* Do not add variables which refer to unsupported types. */
- if (btf_removed_type_p (var->dvd_type))
+ if (!voids.contains (var->dvd_type) && btf_removed_type_p (var->dvd_type))
return 1;
arg_ctfc->ctfc_vars_list[num_vars_added] = var;
@@ -1073,15 +1075,49 @@ btf_init_postprocess (void)
{
ctf_container_ref tu_ctfc = ctf_get_tu_ctfc ();
- size_t i;
- size_t num_ctf_types = tu_ctfc->ctfc_types->elements ();
-
holes.create (0);
voids.create (0);
num_types_added = 0;
num_types_created = 0;
+ /* Workaround for 'const void' variables. These variables are sometimes used
+ in eBPF programs to address kernel symbols. DWARF does not generate const
+ qualifier on void type, so we would incorrectly emit these variables
+ without the const qualifier.
+ Unfortunately we need the TREE node to know it was const, and we need
+ to create the const modifier type (if needed) now, before making the types
+ list. So we can't avoid iterating with FOR_EACH_VARIABLE here, and then
+ again when creating the DATASEC entries. */
"Dot, space, space, new sentence." in 3 places.
+ ctf_id_t constvoid_id = CTF_NULL_TYPEID;
+ varpool_node *var;
+ FOR_EACH_VARIABLE (var)
+{
+ if (!var->decl)
+ continue;
+
+ tree type = TREE_TYPE (var->decl);
+ if (type && VOID_TYPE_P (type) && TYPE_READONLY (type))
+ {
+ dw_die_ref die = lookup_decl_die (var->decl);
+ if (die == NULL)
+ continue;
+
+ ctf_dvdef_ref dvd = ctf_dvd_lookup (tu_ctfc, die);
+ if (dvd == NULL)
+ continue;
+
+ /* Create the 'const' modifier type for void. */
+ if (constvoid_id == CTF_NULL_TYPEID)
+ constvoid_id = ctf_add_reftype (tu_ctfc, CTF_ADD_ROOT,
+ dvd->dvd_type, CTF_K_CONST, NULL);
No de-duplication of the const void type. I assume libbpf will take
care of this eventually.
+ dvd->dvd_type = constvoid_id;
+ }
+}
+
+ size_t i;
+ size_t num_ctf_types = tu_ctfc->ctfc_types->elements ();
+
if (num_ctf_types)
{
init_btf_id_map (num_ctf_types + 1);
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
new file mode 100644
index 000..f90fa773a4b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
@@ -0,0 +1,25 @@
+/* Test BTF generation for extern const void symbols.
+ BTF_KIND_VAR records should be emitted for such symbols if they are used,
+ as well as a corresponding entry in the appropriate DATASEC record. */
+
+/* { dg-do compile } */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* Expect 1 variable record only for foo, with 'extern' (2) linkage. */
+/* { dg-final { scan-assembler-times "\[\t \]0xe00\[\t
\]+\[^\n\]*btv_info" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btv_linkage" 1
} } */
+
+/* { dg-final { scan-assembler-times "ascii \"foo.0\"\[\t
\]+\
Re: [PATCH 1/3] btf: add 'extern' linkage for variables [PR106773]
Hi David,
On 12/7/22 12:57, David Faust wrote:
Add support for the 'extern' linkage value for BTF_KIND_VAR records,
which is used for variables declared as extern in the source file.
PR target/106773
gcc/
* btfout.cc (BTF_LINKAGE_STATIC): New define.
(BTF_LINKAGE_GLOBAL): Likewise.
(BTF_LINKAGE_EXTERN): Likewise.
(btf_collect_datasec): Mark extern variables as such.
(btf_asm_varent): Accomodate 'extern' linkage.
gcc/testsuite/
* gcc.dg/debug/btf/btf-variables-4.c: New test.
include/
* btf.h (struct btf_var): Update comment to note 'extern' linkage.
---
gcc/btfout.cc | 9 ++-
.../gcc.dg/debug/btf/btf-variables-4.c| 24 +++
include/btf.h | 2 +-
3 files changed, 33 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index aef9fd70a28..a1c6266a7db 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -66,6 +66,10 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES];
#define BTF_INVALID_TYPEID 0x
+#define BTF_LINKAGE_STATIC 0
+#define BTF_LINKAGE_GLOBAL 1
+#define BTF_LINKAGE_EXTERN 2
+
I was about to suggest to rename these to use the same name as used in
the kernel btf.h. What is used there is:
BTF_VAR_STATIC = 0,
BTF_VAR_GLOBAL_ALLOCATED = 1,
BTF_VAR_GLOBAL_EXTERN = 2,
But after looking at the Patch 3/3, I see you reuse these definitions
for functions as well. I just find the names confusing on the first look
- "BTF_LINKAGE_STATIC".
Naming aside, what do you think about adding the defines to
include/btf.h instead ?
/* Mapping of CTF variables to the IDs they will be assigned when they are
converted to BTF_KIND_VAR type records. Strictly accounts for the index
from the start of the variable type entries, does not include the number
@@ -314,6 +318,9 @@ btf_collect_datasec (ctf_container_ref ctfc)
continue;
const char *section_name = node->get_section ();
+ /* Mark extern variables. */
+ if (DECL_EXTERNAL (node->decl))
+ dvd->dvd_visibility = BTF_LINKAGE_EXTERN;
This made me think about the following case.
extern const char a[];
const char a[] = "foo";
What is the expected BTF for this? Since BTF can differentiate between
the non-defining extern variable declaration, I expected to see two
variables with different "linkage". At this time I see, two variables
with global linkage but different types:
.long 0xe00 # btv_info
.long 0x4 # btv_type
.long 0x1 # btv_linkage
.long 0x1f# btv_name
.long 0xe00 # btv_info
.long 0x7 # btv_type
.long 0x1 # btv_linkage
.long 0x60# btt_name
if (section_name == NULL)
{
@@ -676,7 +683,7 @@ btf_asm_varent (ctf_dvdef_ref var)
dw2_asm_output_data (4, var->dvd_name_offset, "btv_name");
dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_VAR, 0, 0), "btv_info");
dw2_asm_output_data (4, get_btf_id (var->dvd_type), "btv_type");
- dw2_asm_output_data (4, (var->dvd_visibility ? 1 : 0), "btv_linkage");
+ dw2_asm_output_data (4, var->dvd_visibility, "btv_linkage");
}
/* Asm'out a member description following a BTF_KIND_STRUCT or
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
new file mode 100644
index 000..d77600bae1c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
@@ -0,0 +1,24 @@
+/* Test BTF generation for extern variables. */
+
+/* { dg-do compile } */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* Expect 4 variables. */
+/* { dg-final { scan-assembler-times "\[\t \]0xe00\[\t
\]+\[^\n\]*btv_info" 4 } } */
+
+/* 2 extern, 1 global, 1 static. */
+/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*btv_linkage" 1 }
} */
+/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btv_linkage" 1
} } */
+/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btv_linkage" 2
} } */
+
+extern int a;
+extern const int b;
+int c;
+static const int d = 5;
+
+int foo (int x)
+{
+ c = a + b + x;
+
+ return c + d;
+}
diff --git a/include/btf.h b/include/btf.h
index eba67f9d599..9a757ce5bc9 100644
--- a/include/btf.h
+++ b/include/btf.h
@@ -182,7 +182,7 @@ struct btf_param
information about the variable. */
struct btf_var
{
- uint32_t linkage;/* Currently only 0=static or 1=global. */
+ uint32_t linkage;/* 0=static, 1=global, 2=extern. */
};
/* BTF_KIND_DATASEC is followed by VLEN struct btf_var_secinfo entries,
Re: [PATCH v4] btf: Add support to BTF_KIND_ENUM64 type
On 10/21/22 2:28 AM, Indu Bhagat via Gcc-patches wrote:
On 10/19/22 19:05, Guillermo E. Martinez wrote:
Hello,
The following is patch v4 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v3:
+ Remove `ctf_enum_binfo' structure.
+ Remove -m{little,big}-endian from dg-options in testcase.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
Thanks Guillermo.
LGTM.
Pushed on behalf of Guillermo.
Thanks
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8
The btf_type is followed by info.vlen number of:
struct btf_enum64
{
uint32_t name_off; /* Offset in string section of enumerator
name. */
uint32_t val_lo32; /* lower 32-bit value for a 64-bit value
Enumerator */
uint32_t val_hi32; /* high 32-bit value for a 64-bit value
Enumerator */
};
So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field dtd_enum_unsigned in ctf_dtdef structure to distinguish
when CTF enum is a signed or unsigned type, later that information is
used to encode the BTF enum type.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Compute enumeration size
depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumeration type sign
using dtd_enum_unsigned field for both: BTF_KIND_ENUM{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type, writing the enumerator constant value for
32 bits, if it's 64 bits then explicitly writes lower 32-bits
value and higher 32-bits value.
(output_asm_btf_enum_list): Add enumeration size argument.
* ctfc.cc (ctf_add_enum): New argument to represent CTF enum
basic information.
(ctf_add_generic): Use of ei_{name. size, unsigned} to build the
dtd structure containing enumeration information.
(ctf_add_enumerator): Update comment mention support for BTF
enumeration in 64-bits.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Extract signedness
for enumeration type and use it in ctf_add_enum.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
information.
(ctf_dtdef): New field to describe enum signedness.
include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
---
gcc/btfout.cc | 30 ++---
gcc/ctfc.cc | 13 +++---
gcc/ctfc.h | 5 ++-
gcc/dwarf2ctf.cc | 5 ++-
gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c | 2 +-
gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 44 +++
include/btf.h | 19 ++--
7 files changed, 100 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..aef9fd70a28 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
break;
case BTF_KIND_ENUM:
- vlen_bytes += vlen * sizeof (struct btf_enum);
+ vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+ ? vlen * sizeof (struct btf_enum64)
+ : vlen * sizeof (struct btf_enum);
break;
case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc,
ctf_dtdef_ref dtd)
btf_size_type = 0;
}
+ if (btf_kind == BTF_KIND_ENUM)
+ {
+ btf_kflag = dtd->dtd_enum_unsigned
+ ? BTF_KF_ENUM_UNSIGNED
+ : BTF_KF_ENUM_SIGNED;
+ if (dtd->dtd_data.ctti_size == 0x8)
+ btf_kind = BTF_KIND_ENUM64;
+ }
+
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag,
btf_vlen),
"btt_info: kind=%u, kflag=%u, vlen=%u",
@@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc,
ctf_dtdef_ref dtd)
case BTF_KIND_UNION:
case BTF_KIND_ENUM:
case BTF_KIND_DATASEC:
+ case BTF_KIND_ENUM64:
dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
dtd->dtd_data.ctti_size);
return;
@@ -707,13 +719,19 @@ btf_asm_sou_member (ctf_container_ref ctfc,
ctf_dmdef_t * dmd)
}
}
-/* Asm'out an enum constant following a BTF_KIND_ENUM. */
+/* Asm'out an enum constant following a BTF_KIND_ENUM{,64}. */
static void
-
Re: [PATCH v4] btf: Add support to BTF_KIND_ENUM64 type
On 10/19/22 19:05, Guillermo E. Martinez wrote:
Hello,
The following is patch v4 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v3:
+ Remove `ctf_enum_binfo' structure.
+ Remove -m{little,big}-endian from dg-options in testcase.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
Thanks Guillermo.
LGTM.
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8
The btf_type is followed by info.vlen number of:
struct btf_enum64
{
uint32_t name_off; /* Offset in string section of enumerator name. */
uint32_t val_lo32; /* lower 32-bit value for a 64-bit value Enumerator
*/
uint32_t val_hi32; /* high 32-bit value for a 64-bit value Enumerator
*/
};
So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field dtd_enum_unsigned in ctf_dtdef structure to distinguish
when CTF enum is a signed or unsigned type, later that information is
used to encode the BTF enum type.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumeration type sign
using dtd_enum_unsigned field for both: BTF_KIND_ENUM{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type, writing the enumerator constant value for
32 bits, if it's 64 bits then explicitly writes lower 32-bits
value and higher 32-bits value.
(output_asm_btf_enum_list): Add enumeration size argument.
* ctfc.cc (ctf_add_enum): New argument to represent CTF enum
basic information.
(ctf_add_generic): Use of ei_{name. size, unsigned} to build the
dtd structure containing enumeration information.
(ctf_add_enumerator): Update comment mention support for BTF
enumeration in 64-bits.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Extract signedness
for enumeration type and use it in ctf_add_enum.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
information.
(ctf_dtdef): New field to describe enum signedness.
include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
---
gcc/btfout.cc | 30 ++---
gcc/ctfc.cc | 13 +++---
gcc/ctfc.h| 5 ++-
gcc/dwarf2ctf.cc | 5 ++-
gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c | 2 +-
gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 44 +++
include/btf.h | 19 ++--
7 files changed, 100 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..aef9fd70a28 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
break;
case BTF_KIND_ENUM:
- vlen_bytes += vlen * sizeof (struct btf_enum);
+ vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+ ? vlen * sizeof (struct btf_enum64)
+ : vlen * sizeof (struct btf_enum);
break;
case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
btf_size_type = 0;
}
+ if (btf_kind == BTF_KIND_ENUM)
+{
+ btf_kflag = dtd->dtd_enum_unsigned
+ ? BTF_KF_ENUM_UNSIGNED
+ : BTF_KF_ENUM_SIGNED;
+ if (dtd->dtd_data.ctti_size == 0x8)
+ btf_kind = BTF_KIND_ENUM64;
+ }
+
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
"btt_info: kind=%u, kflag=%u, vlen=%u",
@@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
case BTF_KIND_UNION:
case BTF_KIND_ENUM:
case BTF_KIND_DATASEC:
+case BTF_KIND_ENUM64:
dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
dtd->dtd_data.ctti_size);
return;
@@ -707,13 +719,19 @@ btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t *
dmd)
}
}
-/* Asm'out an enum constant following a BTF_KIND_ENUM. */
+/* Asm'out an enum constant following a BTF_KIND_ENUM{,64}. */
static void
-
Re: [PATCH v3] btf: Add support to BTF_KIND_ENUM64 type
Hi Guillermo,
On 10/14/22 8:55 PM, Guillermo E. Martinez wrote:
Hello,
The following is patch v3 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v2:
+ Add a new `dtd_enum_unsigned' field in `ctf_dtdef' to indicate
signedness of the enum type.
+ Fix endianness for representing BTF enum 64-bits enumerators.
+ Add {little,big}-endian testcases.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8
The btf_type is followed by info.vlen number of:
struct btf_enum64
{
uint32_t name_off; /* Offset in string section of enumerator name. */
uint32_t val_lo32; /* lower 32-bit value for a 64-bit value Enumerator
*/
uint32_t val_hi32; /* high 32-bit value for a 64-bit value Enumerator
*/
};
So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field dtd_enum_unsigned in ctf_dtdef structure to distinguish
when CTF enum is a signed or unsigned type, later that information is
used to encode the BTF enum type.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumeration type sign
using dtd_enum_unsigned field for both: BTF_KIND_ENUM{,64}.
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type, writing the enumerator constant value for
32 bits, if it's 64 bits then explicitly writes lower 32-bits
value and higher 32-bits value.
(output_asm_btf_enum_list): Add enumeration size argument.
* ctfc.cc (ctf_add_enum): New argument to represent CTF enum
basic information.
(ctf_add_generic): Use of ei_{name. size, unsigned} to build the
dtd structure containing enumeration information.
(ctf_add_enumerator): Update comment mention support for BTF
enumeration in 64-bits.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
(ctf_enum_binfo): New type to represent CTF basic enum type
information.
(ctf_dtdef): New field to describe enum signedness.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Use of ctf_enum_binfo
type to pass information to ctf_add_enum to build the enum type.
include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-be-1.c: New testcase.
* gcc.dg/debug/btf/btf-enum64-le-1.c: New testcase.
---
gcc/btfout.cc | 30 ++---
gcc/ctfc.cc | 22 +-
gcc/ctfc.h| 15 +--
gcc/dwarf2ctf.cc | 8 +++-
gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c | 2 +-
.../gcc.dg/debug/btf/btf-enum64-be-1.c| 44 +++
.../gcc.dg/debug/btf/btf-enum64-le-1.c| 44 +++
include/btf.h | 19 ++--
8 files changed, 160 insertions(+), 24 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-be-1.c
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-le-1.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..aef9fd70a28 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
break;
case BTF_KIND_ENUM:
- vlen_bytes += vlen * sizeof (struct btf_enum);
+ vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+ ? vlen * sizeof (struct btf_enum64)
+ : vlen * sizeof (struct btf_enum);
break;
case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
btf_size_type = 0;
}
+ if (btf_kind == BTF_KIND_ENUM)
+{
+ btf_kflag = dtd->dtd_enum_unsigned
+ ? BTF_KF_ENUM_UNSIGNED
+ : BTF_KF_ENUM_SIGNED;
+ if (dtd->dtd_data.ctti_size == 0x8)
+ btf_kind = BTF_KIND_ENUM64;
+ }
+
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
"btt_info: kind=%u, kflag=%u, vlen=%u",
@@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
case BTF_KIND_UNION:
case BTF_KIND_ENUM:
case BTF_KIND_DATASEC:
+case BTF_KI
Re: [PATCH v2] btf: Add support to BTF_KIND_ENUM64 type
Hi Guillermo,
On 10/3/22 7:39 AM, Guillermo E. Martinez via Gcc-patches wrote:
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index 9773358a475..253c36b6a0a 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -604,6 +604,7 @@ ctf_add_enum (ctf_container_ref ctfc, uint32_t
flag, const char * name,
gcc_assert (size <= CTF_MAX_SIZE);
dtd->dtd_data.ctti_size = size;
+ dtd->flags = CTF_ENUM_F_NONE;
ctfc->ctfc_num_stypes++;
@@ -612,7 +613,7 @@ ctf_add_enum (ctf_container_ref ctfc, uint32_t
flag, const char * name,
int
ctf_add_enumerator (ctf_container_ref ctfc, ctf_id_t enid, const
char * name,
- HOST_WIDE_INT value, dw_die_ref die)
+ HOST_WIDE_INT value, uint32_t flags, dw_die_ref die)
{
ctf_dmdef_t * dmd;
uint32_t kind, vlen, root;
@@ -630,10 +631,12 @@ ctf_add_enumerator (ctf_container_ref ctfc,
ctf_id_t enid, const char * name,
gcc_assert (kind == CTF_K_ENUM && vlen < CTF_MAX_VLEN);
- /* Enum value is of type HOST_WIDE_INT in the compiler, dmd_value
is int32_t
- on the other hand. Check bounds and skip adding this enum
value if out of
- bounds. */
- if ((value > INT_MAX) || (value < INT_MIN))
+ /* Enum value is of type HOST_WIDE_INT in the compiler, CTF
enumerators
+ values in ctf_enum_t is limited to int32_t, BTF supports signed
and
+ unsigned enumerators values of 32 and 64 bits, for both debug
formats
+ we use ctf_dmdef_t.dmd_value entry of HOST_WIDE_INT type. So check
+ CTF bounds and skip adding this enum value if out of bounds. */
+ if (!btf_debuginfo_p() && ((value > INT_MAX) || (value < INT_MIN)))
{
/* FIXME - Note this TBD_CTF_REPRESENTATION_LIMIT. */
return (1);
@@ -649,6 +652,7 @@ ctf_add_enumerator (ctf_container_ref ctfc,
ctf_id_t enid, const char * name,
dmd->dmd_value = value;
dtd->dtd_data.ctti_info = CTF_TYPE_INFO (kind, root, vlen + 1);
+ dtd->flags |= flags;
ctf_dmd_list_append (&dtd->dtd_u.dtu_members, dmd);
if ((name != NULL) && strcmp (name, ""))
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index bcf3a43ae1b..a22342b2610 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -125,6 +125,10 @@ typedef struct GTY (()) ctf_itype
#define CTF_FUNC_VARARG 0x1
+/* Enum specific flags. */
+#define CTF_ENUM_F_NONE (0)
+#define CTF_ENUM_F_ENUMERATORS_SIGNED (1 << 0)
+
/* Struct/union/enum member definition for CTF generation. */
typedef struct GTY ((chain_next ("%h.dmd_next"))) ctf_dmdef
@@ -133,7 +137,7 @@ typedef struct GTY ((chain_next ("%h.dmd_next")))
ctf_dmdef
ctf_id_t dmd_type; /* Type of this member (for sou). */
uint32_t dmd_name_offset; /* Offset of the name in str table. */
uint64_t dmd_offset; /* Offset of this member in bits (for
sou). */
- int dmd_value; /* Value of this member (for enum). */
+ HOST_WIDE_INT dmd_value; /* Value of this member (for enum). */
struct ctf_dmdef * dmd_next; /* A list node. */
} ctf_dmdef_t;
I am wondering if you considered adding a member here instead -
something like-
bool dmd_value_signed; /* Signedness for the enumerator. */.
See comment below.
@@ -162,6 +166,7 @@ struct GTY ((for_user)) ctf_dtdef
bool from_global_func; /* Whether this type was added from a global
function. */
uint32_t linkage; /* Used in function types. 0=local,
1=global. */
+ uint32_t flags; /* Flags to describe specific type's
properties. */
union GTY ((desc ("ctf_dtu_d_union_selector (&%1)")))
{
/* struct, union, or enum. */
Instead of carrying this information in ctf_dtdef which is the data
structure for each type in CTF, how about adding a new member in
struct ctf_dmdef? The "flags" member is meant for only enum types, and
hence it will be more appropriate to add to ctf_dmdef as say,
dmd_value_signed.
Yes, `ctf_dtdef' is structure for each type in CTF (including enumeration),
and `ctf_dmdef' keeps information for enumerator, not for the
enumeration type.
Yes, please scrap my earlier suggestion of adding to ctf_dmdef_t.
What do you think about adding something like 'dtd_enum_signedness' to
ctf_dtdef, instead of uint32_t 'flags'; with two possible values of 0
(unsigned) and 1 (signed).
I believe your intention of using the latter is to conserve some memory
in the long run (by reusing the flags field for other types in future if
need be)? I do, however, prefer an explicit member like
dtd_enum_signedness at this time. My reasoning for keeping it explicit
is that it helps code be more readable/maintainable.
Thanks for your patience,
Indu
Re: [PATCH v2] btf: Add support to BTF_KIND_ENUM64 type
On 9/28/22 2:15 PM, Guillermo E. Martinez via Gcc-patches wrote:
Hello GCC team,
The following is patch v2 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v1:
+ Fix typo in commit message.
+ Fix changelog entries.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
Hi Guillermo,
Thanks for your patch.
Sorry for the delay in reviewing this patch. Please see my comments
inlined.
Indu
BTF supports 64-bits enumerators with following encoding:
struct btf_type:
name_off: 0 or offset to a valid C identifier
info.kind_flag: 0 for unsigned, 1 for signed
info.kind: BTF_KIND_ENUM64
info.vlen: number of enum values
size: 1/2/4/8
The btf_type is followed by info.vlen number of:
struct btf_enum64
{
uint32_t name_off; /* Offset in string section of enumerator name. */
uint32_t val_lo32; /* lower 32-bit value for a 64-bit value Enumerator
*/
uint32_t val_hi32; /* high 32-bit value for a 64-bit value Enumerator
*/
};
So, a new btf_enum64 structure was added to represent BTF_KIND_ENUM64
and a new field in ctf_dtdef to represent specific type's properties, in
the particular case for CTF enums it helps to distinguish when its
enumerators values are signed or unsigned, later that information is
used to encode the BTF enum type.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Compute enumeration size depending of
enumerator type btf_enum{,64}.
(btf_asm_type): Update btf_kflag according to enumerators sign,
using correct BPF type in BTF_KIND_ENUMi{,64}.
Typo : i after ENUM
(btf_asm_enum_const): New argument to represent the size of
the BTF enum type.
* ctfc.cc (ctf_add_enum): Use and initialization of flag field to
CTF_ENUM_F_NONE.
(ctf_add_enumerator): New argument to represent CTF flags,
updating the comment and flag vaue according to enumerators
sing.
* ctfc.h (ctf_dmdef): Update dmd_value to HOST_WIDE_INT to allow
use 32/64 bits enumerators.
(ctf_dtdef): Add flags to to describe specific type's properties.
* dwarf2ctf.cc (gen_ctf_enumeration_type): Update flags field
depending when a signed enumerator value is found.
include/
* btf.h (btf_enum64): Add new definition and new symbolic
constant to BTF_KIND_ENUM64 and BTF_KF_ENUM_{UN,}SIGNED.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-enum-1.c: Update testcase, with correct
info.kflags encoding.
* gcc.dg/debug/btf/btf-enum64-1.c: New testcase.
---
gcc/btfout.cc | 24 ---
gcc/ctfc.cc | 14 ---
gcc/ctfc.h| 9 +++-
gcc/dwarf2ctf.cc | 9 +++-
gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c | 2 +-
gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 41 +++
include/btf.h | 19 +++--
7 files changed, 99 insertions(+), 19 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..4b11c867c23 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -223,7 +223,9 @@ btf_calc_num_vbytes (ctf_dtdef_ref dtd)
break;
case BTF_KIND_ENUM:
- vlen_bytes += vlen * sizeof (struct btf_enum);
+ vlen_bytes += (dtd->dtd_data.ctti_size == 0x8)
+ ? vlen * sizeof (struct btf_enum64)
+ : vlen * sizeof (struct btf_enum);
break;
case BTF_KIND_FUNC_PROTO:
@@ -622,6 +624,15 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
btf_size_type = 0;
}
+ if (btf_kind == BTF_KIND_ENUM)
+ {
+ btf_kflag = (dtd->flags & CTF_ENUM_F_ENUMERATORS_SIGNED)
+ ? BTF_KF_ENUM_SIGNED
+ : BTF_KF_ENUM_UNSIGNED;
+ if (dtd->dtd_data.ctti_size == 0x8)
+ btf_kind = BTF_KIND_ENUM64;
+ }
+
See below. If you do add a new member in ctf_dmdef instead (as I
propose), you should ideally iterate over the enumerators
(dtd->dtd_u.dtu_members) to make sure they are all the same signedness.
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
"btt_info: kind=%u, kflag=%u, vlen=%u",
@@ -634,6 +645,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
case BTF_KIND_UNION:
case BTF_KIND_ENUM:
case BTF_KIND_DATASEC:
+case BTF_KIND_ENUM64:
dw2_asm_output_data (4, dtd->dtd_data.ctti_size, "btt_size: %uB",
dtd->dtd_data.ctti_size);
return;
@@ -707,13 +719,13 @@ btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t *
dmd)
}
}
-/* Asm'out an enum constant following a BTF_KIND_ENUM. */
+/* Asm'out
Re: [PATCH] btf: do not skip emitting void variables [PR106773]
On 9/1/22 12:53, David Faust wrote:
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
Tested on bpf-unknown-none and x86_64, no known regressions.
OK?
Hi David,
LGTM.
Thanks,
Thanks.
gcc/ChangeLog:
PR target/106773
* btfout.cc (btf_dvd_emit_preprocess_cb): Do not skip emitting
variables which refer to void types.
gcc/testsuite/ChangeLog:
PR target/106773
* gcc.dg/debug/btf/btf-pr106773.c: New test.
---
gcc/btfout.cc | 2 +-
gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 21 +++
2 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 997a33fa089..37ec662c190 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -430,7 +430,7 @@ btf_dvd_emit_preprocess_cb (ctf_dvdef_ref *slot,
ctf_container_ref arg_ctfc)
ctf_dvdef_ref var = (ctf_dvdef_ref) * slot;
/* Do not add variables which refer to unsupported types. */
- if (btf_removed_type_p (var->dvd_type))
+ if (!voids.contains (var->dvd_type) && btf_removed_type_p (var->dvd_type))
return 1;
arg_ctfc->ctfc_vars_list[num_vars_added] = var;
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
new file mode 100644
index 000..4de15f76546
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c
@@ -0,0 +1,21 @@
+/* Test BTF generation for extern const void symbols.
+ BTF_KIND_VAR records should be emitted for such symbols if they are used.
*/
+
+/* { dg-do compile } */
+/* { dg-options "-O0 -gbtf -dA" } */
+
+/* Expect 1 variable record only for foo. */
+/* { dg-final { scan-assembler-times "\[\t \]0xe00\[\t
\]+\[^\n\]*btv_info" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btv_linkage" 1
} } */
+
+/* { dg-final { scan-assembler-times "ascii \"foo.0\"\[\t
\]+\[^\n\]*btf_string" 1 } } */
+
+extern const void foo;
+extern const void bar;
+
+unsigned long func () {
+ unsigned long x = (unsigned long) &foo;
+
+ return x;
+}
+
Re: [PATCH] btf: do not use the CHAR `encoding' bit for BTF
On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote:
Contrary to CTF and our previous expectations, as per [1], turns out
that in BTF:
1) The `encoding' field in integer types shall not be treated as a
bitmap, but as an enumerated, i.e. these bits are exclusive to each
other.
2) The CHAR bit in `encoding' shall _not_ be set when emitting types
for char nor `unsigned char'.
Hmm...well. At this time, I suggest we make a note of this in the btf.h
for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR
should not be set for char / unsigned char).
Consequently this patch clears the CHAR bit before emitting the
variable part of BTF integral types. It also updates the testsuite
accordingly, expanding it to check for BOOL bits.
[1] https://lore.kernel.org/bpf/a73586ad-f2dc-0401-1eba-2004357b7...@fb.com/T/#t
gcc/ChangeLog:
* btfout.cc (output_asm_btf_vlen_bytes): Do not use the CHAR
encoding bit in BTF.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-int-1.c: Do not check for char bits in
bti_encoding and check for bool bits.
---
gcc/btfout.cc | 4
gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c | 18 +++---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..576f73d47cf 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -914,6 +914,10 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc,
ctf_dtdef_ref dtd)
if (dtd->dtd_data.ctti_size < 1)
break;
+ /* In BTF the CHAR `encoding' seems to not be used, so clear it
+ here. */
+ dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
+
[Added David Faust]
What do you think about doing this in btf_dtd_emit_preprocess_cb () for
types where kind == BTF_KIND_INT. This is the place where BTF specific
massaging of type info takes place.
encoding = BTF_INT_DATA (dtd->dtd_u.dtu_enc.cte_format,
dtd->dtd_u.dtu_enc.cte_offset,
dtd->dtd_u.dtu_enc.cte_bits);
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
index 2381decd6ff..87d9758e9cb 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
@@ -4,7 +4,8 @@
| 0 | encoding | offset | 00 | bits |
encoding:
signed 1 << 24
- char2 << 24
+ char2 << 24 (not used)
+ bool4 << 24
All offsets in this test should be 0.
This test does _not_ check number of bits, as it may vary between targets.
@@ -13,13 +14,14 @@
/* { dg-do compile } */
/* { dg-options "-O0 -gbtf -dA" } */
-/* Check for 8 BTF_KIND_INT types. */
-/* { dg-final { scan-assembler-times "\[\t \]0x100\[\t
\]+\[^\n\]*btt_info" 8 } } */
+/* Check for 9 BTF_KIND_INT types. */
+/* { dg-final { scan-assembler-times "\[\t \]0x100\[\t
\]+\[^\n\]*btt_info" 9 } } */
-/* Check the signed/char flags, but not bit size. */
-/* { dg-final { scan-assembler-times "\[\t \]0x1..\[\t
\]+\[^\n\]*bti_encoding" 3 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x2..\[\t
\]+\[^\n\]*bti_encoding" 1 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x3..\[\t
\]+\[^\n\]*bti_encoding" 1 } } */
+/* Check the signed flags, but not bit size. */
+/* { dg-final { scan-assembler-times "\[\t \]0x1..\[\t
\]+\[^\n\]*bti_encoding" 4 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x..\[\t \]+\[^\n\]*bti_encoding"
3 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x.\[\t \]+\[^\n\]*bti_encoding"
1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x4..\[\t
\]+\[^\n\]*bti_encoding" 1 } } */
/* Check that there is a string entry for each type name. */
/* { dg-final { scan-assembler-times "ascii \"unsigned char.0\"\[\t
\]+\[^\n\]*btf_string" 1 } } */
@@ -42,3 +44,5 @@ signed int f = -66;
unsigned long int g = 77;
signed long int h = 88;
+
+_Bool x = 1;
Re: [PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries
On 7/12/22 8:13 AM, Jose E. Marchesi via Gcc-patches wrote:
The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
annotation reflecting the linkage of functions (static, global). For
whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
instead of adding a variable-part to the record like it is done with
other entry kinds.
This patch makes GCC to include this linkage info in BTF_KIND_FUNC
entries.
Tested in bpf-unknown-none target.
I am not the maintainer of this functionality, but this version looks OK
to me.
Thanks
gcc/ChangeLog:
PR debug/106263
* ctfc.h (struct ctf_dtdef): Add field linkage.
* ctfc.cc (ctf_add_function): Set ctti_linkage.
* dwarf2ctf.cc (gen_ctf_function_type): Pass a linkage for
function types and subprograms.
* btfout.cc (btf_asm_func_type): Emit linkage information for the
function.
(btf_dtd_emit_preprocess_cb): Propagate the linkage information
for functions.
gcc/testsuite/ChangeLog:
PR debug/106263
* gcc.dg/debug/btf/btf-function-4.c: New test.
* gcc.dg/debug/btf/btf-function-5.c: Likewise.
---
gcc/btfout.cc | 6 +-
gcc/ctfc.cc | 3 ++-
gcc/ctfc.h | 3 ++-
gcc/dwarf2ctf.cc| 4 +++-
gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c | 14 ++
gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c | 14 ++
6 files changed, 40 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..594cba84910 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -463,6 +463,7 @@ btf_dtd_emit_preprocess_cb (ctf_container_ref ctfc,
ctf_dtdef_ref dtd)
ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
func_dtd->dtd_data = dtd->dtd_data;
func_dtd->dtd_data.ctti_type = dtd->dtd_type;
+ func_dtd->linkage = dtd->linkage;
vec_safe_push (funcs, func_dtd);
num_types_created++;
@@ -740,7 +741,10 @@ static void
btf_asm_func_type (ctf_dtdef_ref dtd)
{
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
- dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, 0), "btt_info");
+ dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
+ dtd->linkage),
+ "btt_info: kind=%u, kflag=%u, linkage=%u",
+ BTF_KIND_FUNC, 0, dtd->linkage);
dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
}
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index f24e7bff948..9773358a475 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -777,7 +777,7 @@ ctf_add_function_arg (ctf_container_ref ctfc, dw_die_ref
func,
ctf_id_t
ctf_add_function (ctf_container_ref ctfc, uint32_t flag, const char * name,
const ctf_funcinfo_t * ctc, dw_die_ref die,
- bool from_global_func)
+ bool from_global_func, int linkage)
{
ctf_dtdef_ref dtd;
ctf_id_t type;
@@ -791,6 +791,7 @@ ctf_add_function (ctf_container_ref ctfc, uint32_t flag,
const char * name,
type = ctf_add_generic (ctfc, flag, name, &dtd, die);
dtd->from_global_func = from_global_func;
+ dtd->linkage = linkage;
dtd->dtd_data.ctti_info = CTF_TYPE_INFO (CTF_K_FUNCTION, flag, vlen);
/* Caller must make sure CTF types for ctc->ctc_return are already added.
*/
dtd->dtd_data.ctti_type = (uint32_t) ctc->ctc_return;
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index 001e544ef08..bcf3a43ae1b 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -161,6 +161,7 @@ struct GTY ((for_user)) ctf_dtdef
ctf_itype_t dtd_data; /* Type node. */
bool from_global_func; /* Whether this type was added from a global
function. */
+ uint32_t linkage; /* Used in function types. 0=local, 1=global.
*/
union GTY ((desc ("ctf_dtu_d_union_selector (&%1)")))
{
/* struct, union, or enum. */
@@ -423,7 +424,7 @@ extern ctf_id_t ctf_add_forward (ctf_container_ref,
uint32_t, const char *,
extern ctf_id_t ctf_add_typedef (ctf_container_ref, uint32_t, const char *,
ctf_id_t, dw_die_ref);
extern ctf_id_t ctf_add_function (ctf_container_ref, uint32_t, const char *,
- const ctf_funcinfo_t *, dw_die_ref, bool);
+ const ctf_funcinfo_t *, dw_die_ref, bool,
int);
extern ctf_id_t ctf_add_sou (ctf_container_ref, uint32_t, const char *,
uint32_t, size_t, dw_die_ref);
diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc
index a6329ab6ee4..39714c2 100644
--- a/gcc/dwarf2ctf.cc
+++ b/gcc/dwarf2ctf.cc
@@ -644,6 +644,7 @@ gen_
Re: [PATCH] btf: emit linkage information in BTF_KIND_FUNC entries
On 7/8/22 11:30 AM, Jose E. Marchesi via Gcc-patches wrote:
The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
annotation reflecting the linkage of functions (static, global). For
whatever reason they (ab)use the `vlen' field of the BTF_KIND_FUNC entry
instead of adding a variable-part to the record like it is done with
other entry kinds.
For BTF Variables, we have the linkage information in the output section
as "btv_linkage". To propagate that information from DWARF to BTF, we
have the dvd_visibility in struct ctf_dvdef (in ctfc.h). Now that the
linkage information is needed for the BTF_KIND_FUNC entries, what do you
think about - adding something like dtd_visibility to ctf_dtdef.
Updating the BTF format documentation will be useful
https://www.kernel.org/doc/Documentation/bpf/btf.rst. Let's see what can
be done for that...
Also, adding some testcases with the current patch will be great.
I have created PR debug/106263 "BTF_KIND_FUNC type does not encode
linkage" to track this.
This patch makes GCC to include this linkage info in BTF_KIND_FUNC
entries.
Tested in bpf-unknown-none target.
gcc/ChangeLog:
* ctfc.h (struct ctf_itype): Add field ctti_linkage.
* ctfc.cc (ctf_add_function): Set ctti_linkage.
* dwarf2ctf.cc (gen_ctf_function_type): Pass a linkage for
function types and subprograms.
* btfout.cc (btf_asm_func_type): Emit linkage information for the
function.
---
gcc/btfout.cc| 3 ++-
gcc/ctfc.cc | 3 ++-
gcc/ctfc.h | 3 ++-
gcc/dwarf2ctf.cc | 4 +++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..417d87cf519 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -740,7 +740,8 @@ static void
btf_asm_func_type (ctf_dtdef_ref dtd)
{
dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
- dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, 0), "btt_info");
+ dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
+ dtd->dtd_data.ctti_linkage),
"btt_info");
dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
}
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index f24e7bff948..ad7f8bb8e86 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -777,7 +777,7 @@ ctf_add_function_arg (ctf_container_ref ctfc, dw_die_ref
func,
ctf_id_t
ctf_add_function (ctf_container_ref ctfc, uint32_t flag, const char * name,
const ctf_funcinfo_t * ctc, dw_die_ref die,
- bool from_global_func)
+ bool from_global_func, int linkage)
{
ctf_dtdef_ref dtd;
ctf_id_t type;
@@ -792,6 +792,7 @@ ctf_add_function (ctf_container_ref ctfc, uint32_t flag,
const char * name,
dtd->from_global_func = from_global_func;
dtd->dtd_data.ctti_info = CTF_TYPE_INFO (CTF_K_FUNCTION, flag, vlen);
+ dtd->dtd_data.ctti_linkage = linkage;
/* Caller must make sure CTF types for ctc->ctc_return are already added.
*/
dtd->dtd_data.ctti_type = (uint32_t) ctc->ctc_return;
/* Caller must make sure CTF types for function arguments are already added
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index 001e544ef08..273997a2302 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -116,6 +116,7 @@ typedef struct GTY (()) ctf_itype
} _u;
uint32_t ctti_lsizehi; /* High 32 bits of type size in bytes. */
uint32_t ctti_lsizelo; /* Low 32 bits of type size in bytes. */
+ uint32_t ctti_linkage; /* Linkage info for function types. */
} ctf_itype_t;
#define ctti_size _u._size
@@ -423,7 +424,7 @@ extern ctf_id_t ctf_add_forward (ctf_container_ref,
uint32_t, const char *,
extern ctf_id_t ctf_add_typedef (ctf_container_ref, uint32_t, const char *,
ctf_id_t, dw_die_ref);
extern ctf_id_t ctf_add_function (ctf_container_ref, uint32_t, const char *,
- const ctf_funcinfo_t *, dw_die_ref, bool);
+ const ctf_funcinfo_t *, dw_die_ref, bool,
int);
extern ctf_id_t ctf_add_sou (ctf_container_ref, uint32_t, const char *,
uint32_t, size_t, dw_die_ref);
diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc
index a6329ab6ee4..39714c2 100644
--- a/gcc/dwarf2ctf.cc
+++ b/gcc/dwarf2ctf.cc
@@ -644,6 +644,7 @@ gen_ctf_function_type (ctf_container_ref ctfc, dw_die_ref
function,
ctf_funcinfo_t func_info;
uint32_t num_args = 0;
+ int linkage = get_AT_flag (function, DW_AT_external);
ctf_id_t return_type_id;
ctf_id_t function_type_id;
@@ -687,7 +688,8 @@ gen_ctf_function_type (ctf_container_ref ctfc, dw_die_ref
function,
function_name,
(const ctf_funcinfo_t *)&func_info,
function,
- from_global_func);
+
Re: [PATCH 0/3] Fix PR debug/105089
ping On 3/30/22 4:31 PM, Indu Bhagat wrote: Hello, This patch set fixes PR debug/105089. [PS: The first patch in the series "ctfc: get rid of the static variable in ctf_list_add_ctf_vars" is unrelated to the PR and is combined here only for ease of review.] As noted in the PR debug/105089, gcc is emitting two CTF variable records where it sees an extern variable with declaration and definition in the same compilation unit. The CTF format format does not distinguish between the non-defining decl vs. the defining decl, so the correct behaviour wrt the compiler generating the type for such extern variables is to simply emit the type of the defining declaration. Testing Notes: -- bootstrapped and reg tested on x86_64 and aarch64 -- built binutils package with -gctf (with CTF-capable linker) on x86_64, no CTF errors reported. Thanks, Indu Bhagat (3): ctfc: get rid of the static variable in ctf_list_add_ctf_vars () CTF for extern variable fix [PR105089] Refactor and update CTF testcases [PR105089] gcc/ctfc.cc | 62 ++- gcc/ctfc.h| 8 ++- gcc/ctfout.cc | 28 ++--- gcc/dwarf2ctf.cc | 18 +- gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c | 22 +++ gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c | 17 + .../gcc.dg/debug/ctf/ctf-variables-3.c| 22 +++ 7 files changed, 147 insertions(+), 30 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
[PATCH 2/3] 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, however, be pruned by
the link-time de-duplicator as usual, if deemed unused.
2022-03-30 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.
---
gcc/ctfc.cc | 62 ++--
gcc/ctfc.h | 6 -
gcc/ctfout.cc| 24 +--
gcc/dwarf2ctf.cc | 18 --
4 files changed, 98 insertions(+), 12 deletions(-)
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index 6fe44d2e8d49..f24e7bff9487 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -179,6 +179,40 @@ ctf_dvd_lookup (const ctf_container_ref ctfc, dw_die_ref
die)
return NULL;
}
+/* Insert a dummy CTF variable into the list of variables to be ignored. */
+
+static void
+ctf_dvd_ignore_insert (ctf_container_ref ctfc, ctf_dvdef_ref dvd)
+{
+ bool existed = false;
+ ctf_dvdef_ref entry = dvd;
+
+ ctf_dvdef_ref * item = ctfc->ctfc_ignore_vars->find_slot (entry, INSERT);
+ if (*item == NULL)
+ *item = dvd;
+ else
+existed = true;
+ /* Duplicate variable records not expected to be inserted. */
+ gcc_assert (!existed);
+}
+
+/* Lookup the dummy CTF variable given the DWARF die for the non-defining
+ decl to be ignored. */
+
+bool
+ctf_dvd_ignore_lookup (const ctf_container_ref ctfc, dw_die_ref die)
+{
+ ctf_dvdef_t entry;
+ entry.dvd_key = die;
+
+ ctf_dvdef_ref * slot = ctfc->ctfc_ignore_vars->find_slot (&entry, NO_INSERT);
+
+ if (slot)
+return true;
+
+ return false;
+}
+
/* Append member definition to the list. Member list is a singly-linked list
with list start pointing to the head. */
@@ -666,9 +700,10 @@ ctf_add_member_offset (ctf_container_ref ctfc, dw_die_ref
sou,
int
ctf_add_variable (ctf_container_ref ctfc, const char * name, ctf_id_t ref,
- dw_die_ref die, unsigned int external_vis)
+ dw_die_ref die, unsigned int external_vis,
+ dw_die_ref die_var_decl)
{
- ctf_dvdef_ref dvd;
+ ctf_dvdef_ref dvd, dvd_ignore;
gcc_assert (name);
@@ -680,6 +715,24 @@ ctf_add_variable (ctf_container_ref ctfc, const char *
name, ctf_id_t ref,
dvd->dvd_name = ctf_add_string (ctfc, name, &(dvd->dvd_name_offset));
dvd->dvd_visibility = external_vis;
dvd->dvd_type = ref;
+
+ /* If DW_AT_specification attribute e
[PATCH 3/3] 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.
Further, 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-03-30 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.
---
gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c | 22 ++-
gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c | 17 ++
.../gcc.dg/debug/ctf/ctf-variables-3.c| 22 +++
3 files changed, 46 insertions(+), 15 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
index 2a19da050fe7..4721c4fb2f97 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c
@@ -5,34 +5,26 @@
TBD_CTF_FORMAT_OPEN_ISSUES (1) -
This testcase makes a note of the case of a probable misrepresentation.
- See Note 1 and Note 2 below.
+ See Note 1 below.
In the CTF section, these types are encoded as :
Variables:
- _CTF_NEWSTR -> 7: const char [0] (size 0x0)
- _CTF_SECTION -> 6: const char [5] (size 0x5)
- b1 -> 2: int [0] (size 0x0)
- b2 -> 3: int [0] (size 0x0)
+ b1 -> 3: int [0] (size 0x0)
+ b2 -> 5: int [0] (size 0x0)
Note 1 : There is misrepresentation in that b1 and b2 are specified
differently by the user.
-Note 2 : It is arguable though whether the representation for
-_CTF_NEWSTR is incorrect. */
+
+In this testcase, two CTF array records each of type int [0] is expected.
*/
/* { dg-do compile ) */
/* { dg-options "-O0 -gctf -dA" } */
-/* { dg-final { scan-assembler-times "0x1200\[\t \]+\[^\n\]*ctt_info" 5 }
} */
+/* { dg-final { scan-assembler-times "0x1200\[\t \]+\[^\n\]*ctt_info" 2 }
} */
-/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*cta_nelems" 3 }
} */
-/* { dg-final { scan-assembler-times "\[\t \]0x5\[\t \]+\[^\n\]*cta_nelems" 1
} } */
+/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*cta_nelems" 2 }
} */
static int b1[] = {};
int b2[0];
-
-const char _CTF_SECTION[] = ".ctf";
-
-extern const char _CTF_NEWSTR[];
-const char _CTF_NEWSTR[] = "ctfinfo";
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
new file mode 100644
index ..ec504412ef56
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c
@@ -0,0 +1,17 @@
+/* CTF generation for unsized (but initialized) arrays
+
+ In this testcase, one CTF array type record of size 5 is expected.
+
+ Variables:
+ _CTF_SECTION -> 5: const const char [5] (size 0x5) -> 4: const char [5]
(size 0x5)
+
+*/
+
+/* { dg-do compile ) */
+/* { dg-options "-O0 -gctf -dA" } */
+
+/* { dg-final { scan-assembler-times "0x1200\[\t \]+\[^\n\]*ctt_info" 1 }
} */
+
+/* { dg-final { scan-assembler-times "\[\t \]0x5\[\t \]+\[^\n\]*cta_nelems" 1
} } */
+
+const char _CTF_SECTION[] = ".ctf";
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
new file mode 100644
index ..8aea1e82749e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c
@@ -0,0 +1,22 @@
+/* CTF generation for extern variable with defining and non-defining decl
+ in the same CU.
+
+ This testcase checks the case when a non-defining decl is followed by
+ a defining decl for the same variable. See PR debug/105089.
+
+ In this testcase, although two CTF array types are generated, only a
+ single CTF variable and a single entry in the CTF object info section
+ are expected. */
+
+/* { dg-do compile ) */
+/* { dg-options "-O0 -gctf -dA" } */
+
+/* { dg-final { scan-assembler-times "0x1200\[\t
[PATCH 1/3] ctfc: get rid of the static variable in ctf_list_add_ctf_vars ()
2022-03-28 Indu Bhagat
gcc/ChangeLog:
* ctfc.h (struct ctf_container): Introduce a new member.
* ctfout.cc (ctf_list_add_ctf_vars): Use it instead of static
variable.
---
gcc/ctfc.h| 2 ++
gcc/ctfout.cc | 4 +---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index 18c93c802a06..4ce756c728a7 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -301,6 +301,8 @@ typedef struct GTY (()) ctf_container
/* List of pre-processed CTF Variables. CTF requires that the variables
appear in the sorted order of their names. */
ctf_dvdef_t ** GTY ((length ("0"))) ctfc_vars_list;
+ /* Count of pre-processed CTF Variables in the list. */
+ uint64_t ctfc_vars_list_count;
/* List of pre-processed CTF types. CTF requires that a shared type must
appear before the type that uses it. For the compiler, this means types
are emitted in sorted order of their type IDs. */
diff --git a/gcc/ctfout.cc b/gcc/ctfout.cc
index a23d37758019..28a873b2027d 100644
--- a/gcc/ctfout.cc
+++ b/gcc/ctfout.cc
@@ -173,9 +173,7 @@ ctf_calc_num_vbytes (ctf_dtdef_ref ctftype)
static void
ctf_list_add_ctf_vars (ctf_container_ref ctfc, ctf_dvdef_ref var)
{
- /* FIXME - static may not fly with multiple CUs. */
- static int num_vars_added = 0;
- ctfc->ctfc_vars_list[num_vars_added++] = var;
+ ctfc->ctfc_vars_list[ctfc->ctfc_vars_list_count++] = var;
}
/* Initialize the various sections and labels for CTF output. */
--
2.31.1
[PATCH 0/3] Fix PR debug/105089
Hello, This patch set fixes PR debug/105089. [PS: The first patch in the series "ctfc: get rid of the static variable in ctf_list_add_ctf_vars" is unrelated to the PR and is combined here only for ease of review.] As noted in the PR debug/105089, gcc is emitting two CTF variable records where it sees an extern variable with declaration and definition in the same compilation unit. The CTF format format does not distinguish between the non-defining decl vs. the defining decl, so the correct behaviour wrt the compiler generating the type for such extern variables is to simply emit the type of the defining declaration. Testing Notes: -- bootstrapped and reg tested on x86_64 and aarch64 -- built binutils package with -gctf (with CTF-capable linker) on x86_64, no CTF errors reported. Thanks, Indu Bhagat (3): ctfc: get rid of the static variable in ctf_list_add_ctf_vars () CTF for extern variable fix [PR105089] Refactor and update CTF testcases [PR105089] gcc/ctfc.cc | 62 ++- gcc/ctfc.h| 8 ++- gcc/ctfout.cc | 28 ++--- gcc/dwarf2ctf.cc | 18 +- gcc/testsuite/gcc.dg/debug/ctf/ctf-array-2.c | 22 +++ gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c | 17 + .../gcc.dg/debug/ctf/ctf-variables-3.c| 22 +++ 7 files changed, 147 insertions(+), 30 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-array-5.c create mode 100644 gcc/testsuite/gcc.dg/debug/ctf/ctf-variables-3.c -- 2.31.1
[COMMITTED] ctfout: use ctfc_get_num_ctf_vars instead
[Committed as obvious.]
A minor cosmetic fix.
2022-03-28 Indu Bhagat
gcc/ChangeLog:
* ctfout.cc (ctf_preprocess): Use ctfc_get_num_ctf_vars instead.
(output_ctf_vars): Likewise.
---
gcc/ctfout.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/ctfout.cc b/gcc/ctfout.cc
index 9bd918af53c..a23d3775801 100644
--- a/gcc/ctfout.cc
+++ b/gcc/ctfout.cc
@@ -287,7 +287,7 @@ ctf_preprocess (ctf_container_ref ctfc)
ctfc->ctfc_gobjts_list = ggc_vec_alloc(num_global_objts);
}
- size_t num_ctf_vars = ctfc->ctfc_vars->elements ();
+ size_t num_ctf_vars = ctfc_get_num_ctf_vars (ctfc);
if (num_ctf_vars)
{
ctf_dvd_preprocess_arg_t dvd_arg;
@@ -597,7 +597,7 @@ static void
output_ctf_vars (ctf_container_ref ctfc)
{
size_t i;
- size_t num_ctf_vars = ctfc->ctfc_vars->elements ();
+ size_t num_ctf_vars = ctfc_get_num_ctf_vars (ctfc);
if (num_ctf_vars)
{
/* Iterate over the list of sorted vars and output the asm. */
--
2.31.1
Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On 12/30/21 8:59 AM, Palmer Dabbelt wrote:
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the debug
info related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support.
Is the goal here to get the variable "d" out of the small data section
and into the standard data section? It's not clear from your
description .
Neither an ACK nor a NAK at this point. I need to understand better
what you're trying to accomplish.
IIUC that's what this is doing, though the commit message isn't clear at
all. That saind, it might be better to do something like
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..c0ad77d40aa 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -22,9 +22,9 @@
/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset"
7 } } */
/* Check that strings for each DATASEC have been added to the BTF
string table. */
-/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
int a;
long long b;
as whether specific symbols end up in .data or .sdata is really just an
optimization and either should be sufficiently correct.
Yes, I would agree that the test case can be adapted as mentioned. The
purpose of the test case is to check that BTF is correctly generated for
whatever section the symbols end up in.
Adding David Faust in CC for ACK.
Thanks
Indu
IIRC some targets have other flavors of these, PPC's .sdata2 comes to
mind. Not sure if we'd need that to drop their -msdata=none flag.
[COMMITTED] ctfc: remove redundant comma in enumerator list
This also helps get rid of warning
ctfc.h:215:18: warning: comma at end of enumerator list [-Wpedantic]
CTF_DTU_D_SLICE,
gcc/ChangeLog:
* ctfc.h (enum ctf_dtu_d_union_enum): Remove redundant comma.
---
gcc/ctfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
index a0b7e41..701c7ea 100644
--- a/gcc/ctfc.h
+++ b/gcc/ctfc.h
@@ -212,7 +212,7 @@ enum ctf_dtu_d_union_enum {
CTF_DTU_D_ARRAY,
CTF_DTU_D_ENCODING,
CTF_DTU_D_ARGUMENTS,
- CTF_DTU_D_SLICE,
+ CTF_DTU_D_SLICE
};
enum ctf_dtu_d_union_enum
--
1.8.3.1
[PATCH] ctfc: Free CTF type and CTF variable objects in ctfc_delete_container ()
Hello,
This patch fixes an outstanding issue with memory cleanup in the CTF container.
Earlier the two hash tables in the CTF container were not cleaned up in
ctfc_delete_container (). With this patch, we first free up the CTF type and
CTF variable entries in the hash_table slots, followed by emptying of the hash
tables.
Bootstrapped and regression tested on x86_64.
Thanks
Free up the memory held by CTF type and CTF variable objects after CTF debug
information has been emitted. In ctfc_delete_container (), traverse the
hash_table of CTF types and CTF variables and free the memory held by the
respective objects.
gcc/ChangeLog:
* ctfc.c (free_ctf_dtdef_cb): New function.
(free_ctf_dvdef_cb): Likewise.
(ctfc_delete_container): Free hash table contents.
---
gcc/ctfc.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/gcc/ctfc.c b/gcc/ctfc.c
index 73c118e..1f961c9 100644
--- a/gcc/ctfc.c
+++ b/gcc/ctfc.c
@@ -179,6 +179,26 @@ ctf_dvd_lookup (const ctf_container_ref ctfc, dw_die_ref
die)
return NULL;
}
+/* Callback function to free the CTF type from hash table. */
+
+static int
+free_ctf_dtdef_cb (ctf_dtdef_ref * slot, void * arg ATTRIBUTE_UNUSED)
+{
+ if (slot && *slot)
+ggc_free (*slot);
+ return 1;
+}
+
+/* Callback function to free the CTF variable from hash table. */
+
+static int
+free_ctf_dvdef_cb (ctf_dvdef_ref * slot, void * arg ATTRIBUTE_UNUSED)
+{
+ if (slot && *slot)
+ggc_free (*slot);
+ return 1;
+}
+
/* Append member definition to the list. Member list is a singly-linked list
with list start pointing to the head. */
@@ -944,11 +964,16 @@ ctfc_delete_strtab (ctf_strtable_t * strtab)
void
ctfc_delete_container (ctf_container_ref ctfc)
{
- /* FIXME - CTF container can be cleaned up now.
- Will the ggc machinery take care of cleaning up the container structure
- including the hash_map members etc. ? */
if (ctfc)
{
+ ctfc->ctfc_types->traverse (NULL);
+ ctfc->ctfc_types->empty ();
+ ctfc->ctfc_types = NULL;
+
+ ctfc->ctfc_vars->traverse (NULL);
+ ctfc->ctfc_vars->empty ();
+ ctfc->ctfc_types = NULL;
+
ctfc_delete_strtab (&ctfc->ctfc_strtable);
ctfc_delete_strtab (&ctfc->ctfc_aux_strtable);
if (ctfc->ctfc_vars_list)
--
1.8.3.1
Re: [PATCH] ctf: Do not warn for CTF not supported for GNU GIMPLE
On 9/29/21 12:14 AM, Richard Biener wrote:
On Tue, Sep 28, 2021 at 8:52 PM Indu Bhagat via Gcc-patches
wrote:
CTF is supported for C only. Currently, a warning is emitted if the -gctf
command line option is specified for a non-C frontend. This warning is also
used by the GCC testsuite framework - it skips adding -gctf to the list of
debug flags for automated testing, if CTF is not supported for the frontend.
The following warning, however, is not useful in case of LTO:
"lto1: note: CTF debug info requested, but not supported for ‘GNU GIMPLE’
frontend"
This patch disables the generation of the above warning for GNU GIMPLE.
Bootstrapped and regression tested on x86_64.
gcc/ChangeLog:
* toplev.c (process_options): Do not warn for GNU GIMPLE.
---
gcc/toplev.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/gcc/toplev.c b/gcc/toplev.c
index e1688aa..511a343 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1416,14 +1416,16 @@ process_options (void)
debug_info_level = DINFO_LEVEL_NONE;
}
- /* CTF is supported for only C at this time.
- Compiling with -flto results in frontend language of GNU GIMPLE. */
+ /* CTF is supported for only C at this time. */
if (!lang_GNU_C ()
&& ctf_debug_info_level > CTFINFO_LEVEL_NONE)
{
- inform (UNKNOWN_LOCATION,
- "CTF debug info requested, but not supported for %qs frontend",
- language_string);
+ /* Compiling with -flto results in frontend language of GNU GIMPLE. It
+is not useful to warn in that case. */
+ if (!startswith (lang_hooks.name, "GNU GIMPLE"))
please use in_lto_p instead
OK with that change.
in_lto_p is set later in lto_init () (when its time for do_compile ()).
in_lto_p's updated value is not available at this point in
process_options ().
+ inform (UNKNOWN_LOCATION,
+ "CTF debug info requested, but not supported for %qs frontend",
+ language_string);
ctf_debug_info_level = CTFINFO_LEVEL_NONE;
}
--
1.8.3.1
[PATCH] ctf: Do not warn for CTF not supported for GNU GIMPLE
CTF is supported for C only. Currently, a warning is emitted if the -gctf
command line option is specified for a non-C frontend. This warning is also
used by the GCC testsuite framework - it skips adding -gctf to the list of
debug flags for automated testing, if CTF is not supported for the frontend.
The following warning, however, is not useful in case of LTO:
"lto1: note: CTF debug info requested, but not supported for ‘GNU GIMPLE’
frontend"
This patch disables the generation of the above warning for GNU GIMPLE.
Bootstrapped and regression tested on x86_64.
gcc/ChangeLog:
* toplev.c (process_options): Do not warn for GNU GIMPLE.
---
gcc/toplev.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/gcc/toplev.c b/gcc/toplev.c
index e1688aa..511a343 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1416,14 +1416,16 @@ process_options (void)
debug_info_level = DINFO_LEVEL_NONE;
}
- /* CTF is supported for only C at this time.
- Compiling with -flto results in frontend language of GNU GIMPLE. */
+ /* CTF is supported for only C at this time. */
if (!lang_GNU_C ()
&& ctf_debug_info_level > CTFINFO_LEVEL_NONE)
{
- inform (UNKNOWN_LOCATION,
- "CTF debug info requested, but not supported for %qs frontend",
- language_string);
+ /* Compiling with -flto results in frontend language of GNU GIMPLE. It
+is not useful to warn in that case. */
+ if (!startswith (lang_hooks.name, "GNU GIMPLE"))
+ inform (UNKNOWN_LOCATION,
+ "CTF debug info requested, but not supported for %qs frontend",
+ language_string);
ctf_debug_info_level = CTFINFO_LEVEL_NONE;
}
--
1.8.3.1
[PATCH] debug/102507: ICE in btf_finalize when compiling with -gbtf
Fix the free'up of btf_var_ids hash_map in btf_finalize (). Testing notes: - Bootstrapped GCC with -gbtf as an experiment. - Usual bootstrap and regression testing on x86_64. - BPF backend testing - make all-gcc, reg tested bpf.exp, btf.exp and ctf.exp. (tested using David Faust's config.gcc patch posted earlier https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580422.html) gcc/ChangeLog: PR debug/102507 * btfout.c (GTY): Add GTY (()) albeit for cosmetic only purpose. (btf_finalize): Empty the hash_map btf_var_ids. --- gcc/btfout.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/btfout.c b/gcc/btfout.c index cdc6c63..a787815 100644 --- a/gcc/btfout.c +++ b/gcc/btfout.c @@ -70,7 +70,7 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES]; converted to BTF_KIND_VAR type records. Strictly accounts for the index from the start of the variable type entries, does not include the number of types emitted prior to the variable records. */ -static hash_map *btf_var_ids; +static GTY (()) hash_map *btf_var_ids; /* Mapping of type IDs from original CTF ID to BTF ID. Types do not map 1-to-1 from CTF to BTF. To avoid polluting the CTF container when updating @@ -1119,12 +1119,12 @@ btf_finalize (void) funcs = NULL; + btf_var_ids->empty (); + btf_var_ids = NULL; + free (btf_id_map); btf_id_map = NULL; - ggc_free (btf_var_ids); - btf_var_ids = NULL; - ctf_container_ref tu_ctfc = ctf_get_tu_ctfc (); ctfc_delete_container (tu_ctfc); tu_ctfc = NULL; -- 1.8.3.1
Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
On 8/26/21 11:12 PM, Richard Biener wrote:
On Thu, Aug 26, 2021 at 8:55 PM Indu Bhagat wrote:
On 8/26/21 3:03 AM, Richard Biener wrote:
On Tue, Aug 24, 2021 at 7:07 PM Indu Bhagat wrote:
On 8/18/21 12:00 AM, Richard Biener wrote:
On Tue, Aug 17, 2021 at 7:26 PM Indu Bhagat wrote:
On 8/17/21 1:04 AM, Richard Biener wrote:
On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat wrote:
On 8/10/21 4:54 AM, Richard Biener wrote:
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
wrote:
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.
Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.
In principle, I agree the approach to split generate/emit CTF/BTF like
you mention is ideal. But, the BTF CO-RE relocations format is such
that the .BTF section cannot be finalized until .BTF.ext contents are
all fully known (David Faust summarizes this issue in the other thread
"[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
usecase".)
In summary, the .BTF.ext section refers to strings in the .BTF section.
These strings are added at the time the CO-RE relocations are added.
Recall that the .BTF section's header has information about the .BTF
string table start offset and length. So, this means the "CTF part" (or
the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
because it's not ready yet. If it is still unclear, please let me know.
My judgement here is that the BTF format itself is not amenable to split
early/late emission like DWARF. BTF has no linker support yet either.
But are the strings used for the CO-RE relocations not all present already?
Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE
part wants to output sth like "foo->bar.baz" (which IMHO would be quite
stupid also for size purposes)?
Yes, the latter ("foo->bar.baz") is closer to what the format does for
CO-RE relocations!
That said, fix the format.
Alternatively hand the CO-RE part its own string table (what's the fuss
with re-using the CTF string table if there's nothing to share ...)
BTF and .BTF.ext formats are specified already by implementations in the
kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the
mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats
have been defined already by the BPF kernel developers/associated
entities. At this time, we as GCC developers simply extending the BPF
backend/BTF generation support in GCC, cannot fix the format. That ship
has sailed.
Hmm, well. How about emitting .BTF.ext.string from GCC and have the linker
merge the .BTF.ext.string section with the CTF string section then? You can't
really say "the ship has sailed" if I read the CTF webpage - there seems to be
many format changes planned.
Well. Guess that was it from my side on the topic of ranting about the
not well thought out debug format ;)
Richard.
Hello Richard,
As we clarified in this thread, BTF/CO-RE format cannot be changed. What
are your thoughts on this patch set now ? Is this OK ?
Since the issue is intrinsic to BTF/CO-RE and not the actual target can we
do w/o a target hook by just gating on BTF_WITH_CORE as debug format
or so?
Richard.
The issue is intrinsic to BTF debug format *when* CO-RE is in effect, so
it is not entirely target independent because the whole "Compile Once -
Run Everywhere" scheme is BPF backend specific.
I see.
The debug information generation routines need to know if CO-RE is in
effect (to finalize BTF debug info generation late and not early). Now,
because it is the user who selects it via the -mco-re option, we need to
have a way to detect this at run-time. Guarding it with a definition
like BTF_WITH_CORE (is this what you meant?) will not work.
I was thinking about having BTF_CORE_DEBUG in addition to BTF_DEBUG
and thus have this part of the debug info format. That would be
straight-forward
in case the option to enable it were not backend specific but I guess it might
be valid for the backend to alter ops->x_write_symbols in the backend
option processing code.
This is doable. I updated the patch series and have posted V3.
Thanks
Indu
But, yes, we
Re: DWARF for extern variable
On 8/24/21 12:55 AM, Richard Biener wrote: On Mon, Aug 23, 2021 at 11:18 PM Indu Bhagat via Gcc-patches wrote: Hello, What is the expected DWARF for extern variable in the following cases? I am seeing that the DWARF generated is different with gcc8.4.1 vs gcc-trunk. Testcase 2 -- extern const char a[]; const char a[] = "testme"; Testcase 2 Behavior - Both gcc-trunk and gcc8.4.1 generate two DW_TAG_variable DIEs (the defining decl holds the reference to the non-defining decl via DW_AT_specification) - But gcc8.4.1 does not generate any DWARF for the type of the defining decl (const char[7]) but gcc-trunk does. ## DWARF for testcase 2 with gcc-trunk is as follows: <...> <1><22>: Abbrev Number: 2 (DW_TAG_array_type) <23> DW_AT_type: <0x39> <27> DW_AT_sibling : <0x2d> <2><2b>: Abbrev Number: 5 (DW_TAG_subrange_type) <2><2c>: Abbrev Number: 0 <1><2d>: Abbrev Number: 1 (DW_TAG_const_type) <2e> DW_AT_type: <0x22> <1><32>: Abbrev Number: 3 (DW_TAG_base_type) <33> DW_AT_byte_size : 1 <34> DW_AT_encoding: 6(signed char) <35> DW_AT_name: (indirect string, offset: 0x2035): char <1><39>: Abbrev Number: 1 (DW_TAG_const_type) <3a> DW_AT_type: <0x32> <1><3e>: Abbrev Number: 6 (DW_TAG_variable) <3f> DW_AT_name: a <41> DW_AT_decl_file : 1 <42> DW_AT_decl_line : 1 <43> DW_AT_decl_column : 19 <44> DW_AT_type: <0x2d> <48> DW_AT_external: 1 <48> DW_AT_declaration : 1 <1><48>: Abbrev Number: 2 (DW_TAG_array_type) <49> DW_AT_type: <0x39> <4d> DW_AT_sibling : <0x58> <2><51>: Abbrev Number: 7 (DW_TAG_subrange_type) <52> DW_AT_type: <0x5d> <56> DW_AT_upper_bound : 6 <2><57>: Abbrev Number: 0 <1><58>: Abbrev Number: 1 (DW_TAG_const_type) <59> DW_AT_type: <0x48> <1><5d>: Abbrev Number: 3 (DW_TAG_base_type) <5e> DW_AT_byte_size : 8 <5f> DW_AT_encoding: 7(unsigned) <60> DW_AT_name: (indirect string, offset: 0x2023): long unsigned int <1><64>: Abbrev Number: 8 (DW_TAG_variable) <65> DW_AT_specification: <0x3e> <69> DW_AT_decl_line : 2 <6a> DW_AT_decl_column : 12 <6b> DW_AT_type: <0x58> I suppose having both a DW_AT_specification and a DW_AT_type is somewhat at odds. It's likely because the definition specifies the size of the array while the specification does not. Not sure what should be best done here. Richard. Hmm..I thought the generated DWARF by gcc-trunk for testcase 2 is coherent and specifies the information in alignment with the source : DW_AT_type of the defining declaration correctly specifies the type to be const char[7] while the DW_AT_specification pointing to the non-defining decl (and with type const char[] with no size info). The DWARF generated by gcc-8.4.1, however, does seem to be missing information though. It should have the information for the defining decl and hence, the size info. i.e., DW_AT_type pointing to a array with DW_TAG_subrange_type with attribute DW_AT_upper_bound = 6 like above. Isn't it ? Indu <6f> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) <1><79>: Abbrev Number: 0 ## DWARF for testcase 2 with gcc8.4.1 is as follows: <1><21>: Abbrev Number: 2 (DW_TAG_array_type) <22> DW_AT_type: <0x38> <26> DW_AT_sibling : <0x2c> <2><2a>: Abbrev Number: 3 (DW_TAG_subrange_type) <2><2b>: Abbrev Number: 0 <1><2c>: Abbrev Number: 4 (DW_TAG_const_type) <2d> DW_AT_type: <0x21> <1><31>: Abbrev Number: 5 (DW_TAG_base_type) <32> DW_AT_byte_size : 1 <33> DW_AT_encoding: 6(signed char) <34> DW_AT_name: (indirect string, offset: 0x1e04): char <1><38>: Abbrev Number: 4 (DW_TAG_const_type) <39> DW_AT_type: <0x31> <1><3d>: Abbrev Number: 6 (DW_TAG_variable) <3e> DW_AT_name: a <40> DW_AT_decl_file : 1 <41> DW_AT_decl_line : 1 <42> DW_AT_decl_column : 19 <43> DW_AT_type: <0x2c> <47> DW_AT_external: 1 <47> DW_AT_declaration : 1 <1><47>: Abbrev Number: 5 (DW_TAG_base_type) <48> DW_AT_byte_size : 8 <49> DW_AT_encoding: 7(unsigned) <4a> DW_AT_name: (indirect string, offset: 0x1df2): long unsigned int <1><4e>: Abbrev Number: 7 (DW_TAG_variable) <4f> DW_AT_specification: <0x3d> <53> DW_AT_decl_line : 2 <54> DW_AT_decl_column : 12 <55> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) <1><5f>: Abbrev Number: 0 Thanks Indu
[PATCH, V3 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase
DWARF generation is split between early and late phases when LTO is in effect.
This poses challenges for CTF/BTF generation especially if late debug info
generation is desirable, as turns out to be the case for BPF CO-RE.
The approach taken here in this patch is:
1. LTO is disabled for BPF CO-RE
The reason to disable LTO for BPF CO-RE is that if LTO is in effect, BPF CO-RE
relocations need to be generated in the LTO link phase _after_ the optimizations
are done. This means we need to devise way to combine early and late BTF. At
this time, in absence of linker support for BTF sections, it makes sense to
steer clear of LTO for BPF CO-RE and bypass the issue.
2. The BPF backend updates the write_symbols with BPF_WITH_CORE_DEBUG to convey
the case that BTF with CO-RE support needs to be generated. This information
is used by the debug info emission routines to defer the emission of BTF/CO-RE
until dwarf2out_finish.
So, in other words,
dwarf2out_early_finish
- Always emit CTF here.
- if (BTF && !BTF_WITH_CORE), emit BTF now.
dwarf2out_finish
- if (BTF_WITH_CORE) emit BTF now.
gcc/ChangeLog:
* dwarf2ctf.c (ctf_debug_finalize): Make it static.
(ctf_debug_early_finish): New definition.
(ctf_debug_finish): Likewise.
* dwarf2ctf.h (ctf_debug_finalize): Remove declaration.
(ctf_debug_early_finish): New declaration.
(ctf_debug_finish): Likewise.
* dwarf2out.c (dwarf2out_finish): Invoke ctf_debug_finish.
(dwarf2out_early_finish): Invoke ctf_debug_early_finish.
---
gcc/dwarf2ctf.c | 54 +-
gcc/dwarf2ctf.h | 4 +++-
gcc/dwarf2out.c | 9 +++--
3 files changed, 51 insertions(+), 16 deletions(-)
diff --git a/gcc/dwarf2ctf.c b/gcc/dwarf2ctf.c
index 5e8a725..b686baf 100644
--- a/gcc/dwarf2ctf.c
+++ b/gcc/dwarf2ctf.c
@@ -917,6 +917,27 @@ gen_ctf_type (ctf_container_ref ctfc, dw_die_ref die)
return type_id;
}
+/* Prepare for output and write out the CTF debug information. */
+
+static void
+ctf_debug_finalize (const char *filename, bool btf)
+{
+ if (btf)
+{
+ btf_output (filename);
+ btf_finalize ();
+}
+
+ else
+{
+ /* Emit the collected CTF information. */
+ ctf_output (filename);
+
+ /* Reset the CTF state. */
+ ctf_finalize ();
+}
+}
+
bool
ctf_do_die (dw_die_ref die)
{
@@ -966,24 +987,31 @@ ctf_debug_init_postprocess (bool btf)
btf_init_postprocess ();
}
-/* Prepare for output and write out the CTF debug information. */
+/* Early finish CTF/BTF debug info. */
void
-ctf_debug_finalize (const char *filename, bool btf)
+ctf_debug_early_finish (const char * filename)
{
- if (btf)
-{
- btf_output (filename);
- btf_finalize ();
-}
+ /* Emit CTF debug info early always. */
+ if (ctf_debug_info_level > CTFINFO_LEVEL_NONE
+ /* Emit BTF debug info early if CO-RE relocations are not
+required. */
+ || (btf_debuginfo_p () && !btf_with_core_debuginfo_p ()))
+ctf_debug_finalize (filename, btf_debuginfo_p ());
+}
- else
-{
- /* Emit the collected CTF information. */
- ctf_output (filename);
+/* Finish CTF/BTF debug info emission. */
- /* Reset the CTF state. */
- ctf_finalize ();
+void
+ctf_debug_finish (const char * filename)
+{
+ /* Emit BTF debug info here when CO-RE relocations need to be generated.
+ BTF with CO-RE relocations needs to be generated when CO-RE is in effect
+ for the BPF target. */
+ if (btf_with_core_debuginfo_p ())
+{
+ gcc_assert (btf_debuginfo_p ());
+ ctf_debug_finalize (filename, btf_debuginfo_p ());
}
}
diff --git a/gcc/dwarf2ctf.h b/gcc/dwarf2ctf.h
index a3cf567..9edbde0 100644
--- a/gcc/dwarf2ctf.h
+++ b/gcc/dwarf2ctf.h
@@ -24,13 +24,15 @@ along with GCC; see the file COPYING3. If not see
#define GCC_DWARF2CTF_H 1
#include "dwarf2out.h"
+#include "flags.h"
/* Debug Format Interface. Used in dwarf2out.c. */
extern void ctf_debug_init (void);
extern void ctf_debug_init_postprocess (bool);
extern bool ctf_do_die (dw_die_ref);
-extern void ctf_debug_finalize (const char *, bool);
+extern void ctf_debug_early_finish (const char *);
+extern void ctf_debug_finish (const char *);
/* Wrappers for CTF/BTF to fetch information from GCC DWARF DIE. Used in
ctfc.c.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 07a479f..3615e68 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -31913,6 +31913,11 @@ dwarf2out_finish (const char *filename)
unsigned char checksum[16];
char dl_section_ref[MAX_ARTIFICIAL_LABEL_BYTES];
+ /* Generate CTF/BTF debug info. */
+ if ((ctf_debug_info_level > CTFINFO_LEVEL_NONE
+ || btf_debuginfo_p ()) && lang_GNU_C ())
+ctf_debug_finish (filename);
+
/* Skip emitting DWARF if not required. */
if (!dwarf_debuginfo_p ())
return;
@@ -32817,8 +32822,8 @@ dwarf2out_early_finish (const char *filename)
ctf_debug_do_cu
[PATCH,V3 2/3] bpf: Add new -mco-re option for BPF CO-RE
-mco-re in the BPF backend enables code generation for the CO-RE usecase. LTO is
disabled for CO-RE compilations.
gcc/ChangeLog:
* config/bpf/bpf.c (bpf_option_override): For BPF backend, disable LTO
support when compiling for CO-RE.
* config/bpf/bpf.opt: Add new command line option -mco-re.
gcc/testsuite/ChangeLog:
* gcc.target/bpf/core-lto-1.c: New test.
---
gcc/config/bpf/bpf.c | 25 +
gcc/config/bpf/bpf.opt| 4
gcc/testsuite/gcc.target/bpf/core-lto-1.c | 9 +
3 files changed, 38 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index e635f9e..7228978 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -54,6 +54,7 @@ along with GCC; see the file COPYING3. If not see
#include "builtins.h"
#include "predict.h"
#include "langhooks.h"
+#include "flags.h"
/* Per-function machine data. */
struct GTY(()) machine_function
@@ -158,6 +159,30 @@ bpf_option_override (void)
{
/* Set the initializer for the per-function status structure. */
init_machine_status = bpf_init_machine_status;
+
+ /* BPF CO-RE support requires BTF debug info generation. */
+ if (TARGET_BPF_CORE && !btf_debuginfo_p ())
+error ("BPF CO-RE requires BTF debugging information, use %<-gbtf%>");
+
+ /* To support the portability needs of BPF CO-RE approach, BTF debug
+ information includes the BPF CO-RE relocations. */
+ if (TARGET_BPF_CORE)
+write_symbols |= BTF_WITH_CORE_DEBUG;
+
+ /* Unlike much of the other BTF debug information, the information necessary
+ for CO-RE relocations is added to the CTF container by the BPF backend.
+ Enabling LTO adds some complications in the generation of the BPF CO-RE
+ relocations because if LTO is in effect, the relocations need to be
+ generated late in the LTO link phase. This poses a new challenge for the
+ compiler to now provide means to combine the early BTF and late BTF CO-RE
+ debug info, similar to DWARF debug info. BTF/CO-RE debug info is not
+ amenable to such a split generation and a later merging.
+
+ In any case, in absence of linker support for BTF sections at this time,
+ it is acceptable to simply disallow LTO for BPF CO-RE compilations. */
+
+ if (flag_lto && TARGET_BPF_CORE)
+sorry ("BPF CO-RE does not support LTO");
}
#undef TARGET_OPTION_OVERRIDE
diff --git a/gcc/config/bpf/bpf.opt b/gcc/config/bpf/bpf.opt
index 916b53c..4493067 100644
--- a/gcc/config/bpf/bpf.opt
+++ b/gcc/config/bpf/bpf.opt
@@ -127,3 +127,7 @@ Generate little-endian eBPF.
mframe-limit=
Target Joined RejectNegative UInteger IntegerRange(0, 32767)
Var(bpf_frame_limit) Init(512)
Set a hard limit for the size of each stack frame, in bytes.
+
+mco-re
+Target Mask(BPF_CORE)
+Generate all necessary information for BPF Compile Once - Run Everywhere.
diff --git a/gcc/testsuite/gcc.target/bpf/core-lto-1.c
b/gcc/testsuite/gcc.target/bpf/core-lto-1.c
new file mode 100644
index 000..927de23
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/core-lto-1.c
@@ -0,0 +1,9 @@
+/* Test -mco-re with -flto.
+
+ -mco-re is used to generate information for BPF CO-RE usecase. To support
+ the generataion of the .BTF and .BTF.ext sections in GCC, -flto is disabled
+ with -mco-re. */
+
+/* { dg-do compile } */
+/* { dg-message "sorry, unimplemented: BPF CO-RE does not support LTO" "" {
target bpf-*-* } 0 } */
+/* { dg-options "-gbtf -mco-re -flto" } */
--
1.8.3.1
[PATCH,V3 0/3] Allow means for late BTF generation for BPF CO-RE
[Changes from V2]
- Instead of target hook, the patch set now adds a new debug format
BTF_WITH_CORE_DEBUG.
- Renamed the BPF option from -mcore to -mco-re.
- Adapted the commit logs a bit.
[End of Changes from V2]
Hello,
This patch series puts the framework in place for late BTF generation (in
dwarf2out_finish). This is needed for the landing of BPF CO-RE support in GCC,
patches for which were posted earlier -
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576719.html.
BPF's Compile Once - Run Everywhere (CO-RE) feature is used to make a compiled
BPF program portable across kernel versions, all this without the need to
recompile the BPF program. A key part of BPF CO-RE capability is the BTF debug
info generated for them.
A traditional BPF program (non CO-RE) will have a .BTF section which contains
the type information in the BTF debug format. In case of CO-RE, however, an
additional section .BTF.ext section is used. The .BTF.ext section contains
the CO-RE relocations. A BPF loader will use the .BTF.ext section along with the
associated .BTF section to adjust some references in the instructions of BPF
program to ensure it is compatible with the required kernel version / headers.
A .BTF.ext section contains the CO-RE relocation records. Roughly, each CO-RE
relocation record will contain the following info:
- offset of BPF instruction to be patched
- the BTF ID of the data structure being accessed by the instruction, and
- an offset to the "access string" - a BTF string which encodes a series of
field accesses to retrieve the field of interest in the instruction.
The .BTF.ext section does not have a string table of its own, so these "access
strings" are placed in the .BTF section string table. The CO-RE relocation
records refer to them by offset into the .BTF string table.
Example of access string encoding:
struct S {
int a;
union {
int _unused;
int b;
char c;
} u[4];
};
struct S *foo = ...;
int x = foo->a; /* encoded as "0:0" */
int y = foo[4]->u[2].b /* encoded as "4:1:2:1" */
char z = foo->u[3].c /* encoded as "0:1:3:2" */
This means that writing out of a .BTF section needs to be delayed until after
these "access strings" have been added by the BPF backend, when CO-RE is in
effect.
High-level design
-
- The CTF container (CTFC) is populated with the compiler-internal
representation for the "type information" at dwarf2out_early_finish time. This
information is used for generation of the .BTF section.
- For CO-RE relocation records, the information needed to generate .BTF.ext
section is added by the BPF backend to the CTF container (CTFC) at expand time.
- A new debug format BTF_WITH_CORE_DEBUG is being added.
- The BPF backend updates the write_symbols variable with BTF_WITH_CORE_DEBUG
debug format signalling the rest of the compiler that BPF/CO-RE is in effect,
and hence the need to generate the BTF CO-RE relocation records.
- BTF debug information is emitted late in dwarf2out_finish when
BTF_WITH_CORE_DEBUG debug format is requested by the user (implicitly via the
command line option -mco-re for the BPF backend).
- Combining early BTF and late BTF/CO-RE debug information is not feasible due
to the way BTF CO-RE format is defined and lack of linker support for the BTF
debug format.
- Lastly, LTO is disallowed to be used together with CO-RE for the BPF target.
Testing Notes
- Bootstrapped and reg tested on x86_64
- make all-gcc for --target=bpf-unknown-none; tested ctf.exp, btf.exp and
bpf.exp
Thanks,
Indu Bhagat (3):
debug: add BTF_WITH_CORE_DEBUG debug format
bpf: Add new -mco-re option for BPF CO-RE
dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase
gcc/config/bpf/bpf.c | 25 ++
gcc/config/bpf/bpf.opt| 4 +++
gcc/dwarf2ctf.c | 54 +++
gcc/dwarf2ctf.h | 4 ++-
gcc/dwarf2out.c | 9 --
gcc/flag-types.h | 6 +++-
gcc/flags.h | 4 +++
gcc/opts.c| 8 +
gcc/testsuite/gcc.target/bpf/core-lto-1.c | 9 ++
9 files changed, 106 insertions(+), 17 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c
--
1.8.3.1
[PATCH,V3 1/3] debug: add BTF_WITH_CORE_DEBUG debug format
To best handle BTF/CO-RE in GCC, a distinct BTF_WITH_CORE_DEBUG debug format is
being added. This helps the compiler detect whether BTF with CO-RE relocations
needs to be emitted.
gcc/ChangeLog:
* flag-types.h (enum debug_info_type): Add new enum
DINFO_TYPE_BTF_WITH_CORE.
(BTF_WITH_CORE_DEBUG): New bitmask.
* flags.h (btf_with_core_debuginfo_p): New declaration.
* opts.c (btf_with_core_debuginfo_p): New definition.
---
gcc/flag-types.h | 6 +-
gcc/flags.h | 4
gcc/opts.c | 8
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 4fb1cb4..cc41b2a 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -31,7 +31,8 @@ enum debug_info_type
DINFO_TYPE_VMS = 4,/* VMS debug info. */
DINFO_TYPE_CTF = 5,/* CTF debug info. */
DINFO_TYPE_BTF = 6,/* BTF debug info. */
- DINFO_TYPE_MAX = DINFO_TYPE_BTF /* Marker only. */
+ DINFO_TYPE_BTF_WITH_CORE = 7, /* BTF debug info with CO-RE
relocations. */
+ DINFO_TYPE_MAX = DINFO_TYPE_BTF_WITH_CORE /* Marker only. */
};
#define NO_DEBUG (0U)
@@ -47,6 +48,9 @@ enum debug_info_type
#define CTF_DEBUG (1U << DINFO_TYPE_CTF)
/* Write BTF debug info (using btfout.c). */
#define BTF_DEBUG (1U << DINFO_TYPE_BTF)
+/* Write BTF debug info for BPF CO-RE usecase (using btfout.c). */
+#define BTF_WITH_CORE_DEBUG (1U << DINFO_TYPE_BTF_WITH_CORE)
+
/* Note: Adding new definitions to handle -combination- of debug formats,
like VMS_AND_DWARF2_DEBUG is not recommended. This definition remains
here for historical reasons. */
diff --git a/gcc/flags.h b/gcc/flags.h
index afedef0..af61bcd 100644
--- a/gcc/flags.h
+++ b/gcc/flags.h
@@ -44,6 +44,10 @@ const char * debug_set_names (uint32_t w_symbols);
extern bool btf_debuginfo_p ();
+/* Return true iff BTF with CO-RE debug info is enabled. */
+
+extern bool btf_with_core_debuginfo_p ();
+
/* Return true iff CTF debug info is enabled. */
extern bool ctf_debuginfo_p ();
diff --git a/gcc/opts.c b/gcc/opts.c
index e050155..1d2d22d 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -135,6 +135,14 @@ btf_debuginfo_p ()
return (write_symbols & BTF_DEBUG);
}
+/* Return TRUE iff BTF with CO-RE debug info is enabled. */
+
+bool
+btf_with_core_debuginfo_p ()
+{
+ return (write_symbols & BTF_WITH_CORE_DEBUG);
+}
+
/* Return TRUE iff CTF debug info is enabled. */
bool
--
1.8.3.1
Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
On 8/26/21 3:03 AM, Richard Biener wrote:
On Tue, Aug 24, 2021 at 7:07 PM Indu Bhagat wrote:
On 8/18/21 12:00 AM, Richard Biener wrote:
On Tue, Aug 17, 2021 at 7:26 PM Indu Bhagat wrote:
On 8/17/21 1:04 AM, Richard Biener wrote:
On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat wrote:
On 8/10/21 4:54 AM, Richard Biener wrote:
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
wrote:
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.
Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.
In principle, I agree the approach to split generate/emit CTF/BTF like
you mention is ideal. But, the BTF CO-RE relocations format is such
that the .BTF section cannot be finalized until .BTF.ext contents are
all fully known (David Faust summarizes this issue in the other thread
"[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
usecase".)
In summary, the .BTF.ext section refers to strings in the .BTF section.
These strings are added at the time the CO-RE relocations are added.
Recall that the .BTF section's header has information about the .BTF
string table start offset and length. So, this means the "CTF part" (or
the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
because it's not ready yet. If it is still unclear, please let me know.
My judgement here is that the BTF format itself is not amenable to split
early/late emission like DWARF. BTF has no linker support yet either.
But are the strings used for the CO-RE relocations not all present already?
Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE
part wants to output sth like "foo->bar.baz" (which IMHO would be quite
stupid also for size purposes)?
Yes, the latter ("foo->bar.baz") is closer to what the format does for
CO-RE relocations!
That said, fix the format.
Alternatively hand the CO-RE part its own string table (what's the fuss
with re-using the CTF string table if there's nothing to share ...)
BTF and .BTF.ext formats are specified already by implementations in the
kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the
mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats
have been defined already by the BPF kernel developers/associated
entities. At this time, we as GCC developers simply extending the BPF
backend/BTF generation support in GCC, cannot fix the format. That ship
has sailed.
Hmm, well. How about emitting .BTF.ext.string from GCC and have the linker
merge the .BTF.ext.string section with the CTF string section then? You can't
really say "the ship has sailed" if I read the CTF webpage - there seems to be
many format changes planned.
Well. Guess that was it from my side on the topic of ranting about the
not well thought out debug format ;)
Richard.
Hello Richard,
As we clarified in this thread, BTF/CO-RE format cannot be changed. What
are your thoughts on this patch set now ? Is this OK ?
Since the issue is intrinsic to BTF/CO-RE and not the actual target can we
do w/o a target hook by just gating on BTF_WITH_CORE as debug format
or so?
Richard.
The issue is intrinsic to BTF debug format *when* CO-RE is in effect, so
it is not entirely target independent because the whole "Compile Once -
Run Everywhere" scheme is BPF backend specific.
The debug information generation routines need to know if CO-RE is in
effect (to finalize BTF debug info generation late and not early). Now,
because it is the user who selects it via the -mco-re option, we need to
have a way to detect this at run-time. Guarding it with a definition
like BTF_WITH_CORE (is this what you meant?) will not work.
But, yes, we can do without a target hook. We can keep a global var in
the BTF context in btfout.c / CTF container (CTFC) which can be updated
by the backend when BPF CO-RE is in effect (the -mco-re option). This
was also considered as an option but the target hook option was chosen
because it appeared to be the GCC's preferred way of conveying
information from the backend. Is keeping global var preferable in this
specific case ?
Indu
Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
On 8/18/21 12:00 AM, Richard Biener wrote:
On Tue, Aug 17, 2021 at 7:26 PM Indu Bhagat wrote:
On 8/17/21 1:04 AM, Richard Biener wrote:
On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat wrote:
On 8/10/21 4:54 AM, Richard Biener wrote:
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
wrote:
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.
Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.
In principle, I agree the approach to split generate/emit CTF/BTF like
you mention is ideal. But, the BTF CO-RE relocations format is such
that the .BTF section cannot be finalized until .BTF.ext contents are
all fully known (David Faust summarizes this issue in the other thread
"[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
usecase".)
In summary, the .BTF.ext section refers to strings in the .BTF section.
These strings are added at the time the CO-RE relocations are added.
Recall that the .BTF section's header has information about the .BTF
string table start offset and length. So, this means the "CTF part" (or
the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
because it's not ready yet. If it is still unclear, please let me know.
My judgement here is that the BTF format itself is not amenable to split
early/late emission like DWARF. BTF has no linker support yet either.
But are the strings used for the CO-RE relocations not all present already?
Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE
part wants to output sth like "foo->bar.baz" (which IMHO would be quite
stupid also for size purposes)?
Yes, the latter ("foo->bar.baz") is closer to what the format does for
CO-RE relocations!
That said, fix the format.
Alternatively hand the CO-RE part its own string table (what's the fuss
with re-using the CTF string table if there's nothing to share ...)
BTF and .BTF.ext formats are specified already by implementations in the
kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the
mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats
have been defined already by the BPF kernel developers/associated
entities. At this time, we as GCC developers simply extending the BPF
backend/BTF generation support in GCC, cannot fix the format. That ship
has sailed.
Hmm, well. How about emitting .BTF.ext.string from GCC and have the linker
merge the .BTF.ext.string section with the CTF string section then? You can't
really say "the ship has sailed" if I read the CTF webpage - there seems to be
many format changes planned.
Well. Guess that was it from my side on the topic of ranting about the
not well thought out debug format ;)
Richard.
Hello Richard,
As we clarified in this thread, BTF/CO-RE format cannot be changed. What
are your thoughts on this patch set now ? Is this OK ?
Thanks
Indu
Thanks for reviewing and voicing your concerns.
Indu
Richard.
DWARF for extern variable
Hello,
What is the expected DWARF for extern variable in the following cases? I
am seeing that the DWARF generated is different with gcc8.4.1 vs gcc-trunk.
Testcase 1
--
extern const char a[];
int foo()
{
return a != 0;
}
Testcase 1 Behavior
-
- gcc-trunk has _no_ DWARF for variable a.
- gcc8.4.1 generates following DW_TAG_variable for extern variable a.
But does not designate it as a non-defining decl (IIUC,
DW_AT_specification is used for such cases?).
<..>
<1><31>: Abbrev Number: 2 (DW_TAG_array_type)
<32> DW_AT_type: <0x48>
<36> DW_AT_sibling : <0x3c>
<2><3a>: Abbrev Number: 3 (DW_TAG_subrange_type)
<2><3b>: Abbrev Number: 0
<1><3c>: Abbrev Number: 4 (DW_TAG_const_type)
<3d> DW_AT_type: <0x31>
<1><41>: Abbrev Number: 5 (DW_TAG_base_type)
<42> DW_AT_byte_size : 1
<43> DW_AT_encoding: 6(signed char)
<44> DW_AT_name: (indirect string, offset: 0x1df6): char
<1><48>: Abbrev Number: 4 (DW_TAG_const_type)
<49> DW_AT_type: <0x41>
<1><4d>: Abbrev Number: 6 (DW_TAG_variable)
<4e> DW_AT_name: a
<50> DW_AT_decl_file : 1
<51> DW_AT_decl_line : 1
<52> DW_AT_decl_column : 19
<53> DW_AT_type: <0x3c>
<57> DW_AT_external: 1
<57> DW_AT_declaration : 1
<..>
---
Testcase 2
--
extern const char a[];
const char a[] = "testme";
Testcase 2 Behavior
- Both gcc-trunk and gcc8.4.1 generate two DW_TAG_variable DIEs (the
defining decl holds the reference to the non-defining decl via
DW_AT_specification)
- But gcc8.4.1 does not generate any DWARF for the type of the defining
decl (const char[7]) but gcc-trunk does.
## DWARF for testcase 2 with gcc-trunk is as follows:
<...>
<1><22>: Abbrev Number: 2 (DW_TAG_array_type)
<23> DW_AT_type: <0x39>
<27> DW_AT_sibling : <0x2d>
<2><2b>: Abbrev Number: 5 (DW_TAG_subrange_type)
<2><2c>: Abbrev Number: 0
<1><2d>: Abbrev Number: 1 (DW_TAG_const_type)
<2e> DW_AT_type: <0x22>
<1><32>: Abbrev Number: 3 (DW_TAG_base_type)
<33> DW_AT_byte_size : 1
<34> DW_AT_encoding: 6(signed char)
<35> DW_AT_name: (indirect string, offset: 0x2035): char
<1><39>: Abbrev Number: 1 (DW_TAG_const_type)
<3a> DW_AT_type: <0x32>
<1><3e>: Abbrev Number: 6 (DW_TAG_variable)
<3f> DW_AT_name: a
<41> DW_AT_decl_file : 1
<42> DW_AT_decl_line : 1
<43> DW_AT_decl_column : 19
<44> DW_AT_type: <0x2d>
<48> DW_AT_external: 1
<48> DW_AT_declaration : 1
<1><48>: Abbrev Number: 2 (DW_TAG_array_type)
<49> DW_AT_type: <0x39>
<4d> DW_AT_sibling : <0x58>
<2><51>: Abbrev Number: 7 (DW_TAG_subrange_type)
<52> DW_AT_type: <0x5d>
<56> DW_AT_upper_bound : 6
<2><57>: Abbrev Number: 0
<1><58>: Abbrev Number: 1 (DW_TAG_const_type)
<59> DW_AT_type: <0x48>
<1><5d>: Abbrev Number: 3 (DW_TAG_base_type)
<5e> DW_AT_byte_size : 8
<5f> DW_AT_encoding: 7(unsigned)
<60> DW_AT_name: (indirect string, offset: 0x2023): long
unsigned int
<1><64>: Abbrev Number: 8 (DW_TAG_variable)
<65> DW_AT_specification: <0x3e>
<69> DW_AT_decl_line : 2
<6a> DW_AT_decl_column : 12
<6b> DW_AT_type: <0x58>
<6f> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0
(DW_OP_addr: 0)
<1><79>: Abbrev Number: 0
## DWARF for testcase 2 with gcc8.4.1 is as follows:
<1><21>: Abbrev Number: 2 (DW_TAG_array_type)
<22> DW_AT_type: <0x38>
<26> DW_AT_sibling : <0x2c>
<2><2a>: Abbrev Number: 3 (DW_TAG_subrange_type)
<2><2b>: Abbrev Number: 0
<1><2c>: Abbrev Number: 4 (DW_TAG_const_type)
<2d> DW_AT_type: <0x21>
<1><31>: Abbrev Number: 5 (DW_TAG_base_type)
<32> DW_AT_byte_size : 1
<33> DW_AT_encoding: 6(signed char)
<34> DW_AT_name: (indirect string, offset: 0x1e04): char
<1><38>: Abbrev Number: 4 (DW_TAG_const_type)
<39> DW_AT_type: <0x31>
<1><3d>: Abbrev Number: 6 (DW_TAG_variable)
<3e> DW_AT_name: a
<40> DW_AT_decl_file : 1
<41> DW_AT_decl_line : 1
<42> DW_AT_decl_column : 19
<43> DW_AT_type: <0x2c>
<47> DW_AT_external: 1
<47> DW_AT_declaration : 1
<1><47>: Abbrev Number: 5 (DW_TAG_base_type)
<48> DW_AT_byte_size : 8
<49> DW_AT_encoding: 7(unsigned)
<4a> DW_AT_name: (indirect string, offset: 0x1df2): long
unsigned int
<1><4e>: Abbrev Number: 7 (DW_TAG_variable)
<4f> DW_AT_specification: <0x3d>
<53> DW_AT_decl_line : 2
<54> DW_AT_decl_column : 12
<55> DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0
(DW_OP_addr: 0)
<1><5f>: Abbrev Number: 0
Thanks
Indu
Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
On 8/18/21 12:00 AM, Richard Biener wrote:
On Tue, Aug 17, 2021 at 7:26 PM Indu Bhagat wrote:
On 8/17/21 1:04 AM, Richard Biener wrote:
On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat wrote:
On 8/10/21 4:54 AM, Richard Biener wrote:
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
wrote:
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.
Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.
In principle, I agree the approach to split generate/emit CTF/BTF like
you mention is ideal. But, the BTF CO-RE relocations format is such
that the .BTF section cannot be finalized until .BTF.ext contents are
all fully known (David Faust summarizes this issue in the other thread
"[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
usecase".)
In summary, the .BTF.ext section refers to strings in the .BTF section.
These strings are added at the time the CO-RE relocations are added.
Recall that the .BTF section's header has information about the .BTF
string table start offset and length. So, this means the "CTF part" (or
the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
because it's not ready yet. If it is still unclear, please let me know.
My judgement here is that the BTF format itself is not amenable to split
early/late emission like DWARF. BTF has no linker support yet either.
But are the strings used for the CO-RE relocations not all present already?
Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE
part wants to output sth like "foo->bar.baz" (which IMHO would be quite
stupid also for size purposes)?
Yes, the latter ("foo->bar.baz") is closer to what the format does for
CO-RE relocations!
That said, fix the format.
Alternatively hand the CO-RE part its own string table (what's the fuss
with re-using the CTF string table if there's nothing to share ...)
BTF and .BTF.ext formats are specified already by implementations in the
kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the
mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats
have been defined already by the BPF kernel developers/associated
entities. At this time, we as GCC developers simply extending the BPF
backend/BTF generation support in GCC, cannot fix the format. That ship
has sailed.
Hmm, well. How about emitting .BTF.ext.string from GCC and have the linker
merge the .BTF.ext.string section with the CTF string section then? You can't
really say "the ship has sailed" if I read the CTF webpage - there seems to be
many format changes planned.
BTF originated from CTF long ago. These are two distinct formats and
have their own independent evolution trail with specific use-cases.
It's true that CTF format has changes planned for V4 and it's open for
folks to give feedback or get involved. But BTF will not be a direct
benefactor of any of those changes, as BPF/BTF ecosystem is evolving
elsewhere (hopefully for the better).
Well. Guess that was it from my side on the topic of ranting about the
not well thought out debug format ;)
Richard.
Thanks for reviewing and voicing your concerns.
Indu
Richard.
gcc/ChangeLog:
* config/bpf/bpf.c (ctfc_debuginfo_early_finish_p): New definition.
(TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P): Undefine and override.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Document the new hook.
* target.def: Add a new hook.
* targhooks.c (default_ctfc_debuginfo_early_finish_p): Likewise.
* targhooks.h (default_ctfc_debuginfo_early_finish_p): Likewise.
---
gcc/config/bpf/bpf.c | 14 ++
gcc/doc/tm.texi | 6 ++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 10 ++
gcc/targhooks.c | 6 ++
gcc/targhooks.h | 2 ++
6 files changed, 40 insertions(+)
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 028013e..85f6b76 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -178,6 +178,20 @@ bpf_option_override (void)
#undef TARGET_OPTION_OVERRIDE
#define TARGET_OPTION_OVERRIDE bpf_option_override
+/* Retu
Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
On 8/17/21 1:04 AM, Richard Biener wrote:
On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat wrote:
On 8/10/21 4:54 AM, Richard Biener wrote:
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
wrote:
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.
Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.
In principle, I agree the approach to split generate/emit CTF/BTF like
you mention is ideal. But, the BTF CO-RE relocations format is such
that the .BTF section cannot be finalized until .BTF.ext contents are
all fully known (David Faust summarizes this issue in the other thread
"[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
usecase".)
In summary, the .BTF.ext section refers to strings in the .BTF section.
These strings are added at the time the CO-RE relocations are added.
Recall that the .BTF section's header has information about the .BTF
string table start offset and length. So, this means the "CTF part" (or
the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
because it's not ready yet. If it is still unclear, please let me know.
My judgement here is that the BTF format itself is not amenable to split
early/late emission like DWARF. BTF has no linker support yet either.
But are the strings used for the CO-RE relocations not all present already?
Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE
part wants to output sth like "foo->bar.baz" (which IMHO would be quite
stupid also for size purposes)?
Yes, the latter ("foo->bar.baz") is closer to what the format does for
CO-RE relocations!
That said, fix the format.
Alternatively hand the CO-RE part its own string table (what's the fuss
with re-using the CTF string table if there's nothing to share ...)
BTF and .BTF.ext formats are specified already by implementations in the
kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the
mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats
have been defined already by the BPF kernel developers/associated
entities. At this time, we as GCC developers simply extending the BPF
backend/BTF generation support in GCC, cannot fix the format. That ship
has sailed.
Thanks for reviewing and voicing your concerns.
Indu
Richard.
gcc/ChangeLog:
* config/bpf/bpf.c (ctfc_debuginfo_early_finish_p): New definition.
(TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P): Undefine and override.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Document the new hook.
* target.def: Add a new hook.
* targhooks.c (default_ctfc_debuginfo_early_finish_p): Likewise.
* targhooks.h (default_ctfc_debuginfo_early_finish_p): Likewise.
---
gcc/config/bpf/bpf.c | 14 ++
gcc/doc/tm.texi | 6 ++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 10 ++
gcc/targhooks.c | 6 ++
gcc/targhooks.h | 2 ++
6 files changed, 40 insertions(+)
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 028013e..85f6b76 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -178,6 +178,20 @@ bpf_option_override (void)
#undef TARGET_OPTION_OVERRIDE
#define TARGET_OPTION_OVERRIDE bpf_option_override
+/* Return FALSE iff -mcore has been specified. */
+
+static bool
+ctfc_debuginfo_early_finish_p (void)
+{
+ if (TARGET_BPF_CORE)
+return false;
+ else
+return true;
+}
+
+#undef TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+#define TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P ctfc_debuginfo_early_finish_p
+
/* Define target-specific CPP macros. This function in used in the
definition of TARGET_CPU_CPP_BUILTINS in bpf.h */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index cb01528..2d5ff05 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -10400,6 +10400,12 @@ Define this macro if GCC should produce debugging
output in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@deftypefn {Target Hook} bool TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P (void)
+This target hook returns nonzero if the CTF Container can allow the
+ emission of the CTF/BTF debug info at the DWARF debug
Re: [PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
On 8/10/21 4:54 AM, Richard Biener wrote:
On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
wrote:
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
Without looking at the dwarf2out.c usage in the next patch - I think
the CTF part
should be always emitted from dwarf2out_early_finish, the "hooks" should somehow
arrange for the alternate output specific data to be preserved until
dwarf2out_finish
time so the late BTF data can be emitted from there.
Lumping everything together now just makes it harder to see what info
is required
to persist and thus make LTO support more intrusive than necessary.
In principle, I agree the approach to split generate/emit CTF/BTF like
you mention is ideal. But, the BTF CO-RE relocations format is such
that the .BTF section cannot be finalized until .BTF.ext contents are
all fully known (David Faust summarizes this issue in the other thread
"[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
usecase".)
In summary, the .BTF.ext section refers to strings in the .BTF section.
These strings are added at the time the CO-RE relocations are added.
Recall that the .BTF section's header has information about the .BTF
string table start offset and length. So, this means the "CTF part" (or
the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
because it's not ready yet. If it is still unclear, please let me know.
My judgement here is that the BTF format itself is not amenable to split
early/late emission like DWARF. BTF has no linker support yet either.
gcc/ChangeLog:
* config/bpf/bpf.c (ctfc_debuginfo_early_finish_p): New definition.
(TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P): Undefine and override.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Document the new hook.
* target.def: Add a new hook.
* targhooks.c (default_ctfc_debuginfo_early_finish_p): Likewise.
* targhooks.h (default_ctfc_debuginfo_early_finish_p): Likewise.
---
gcc/config/bpf/bpf.c | 14 ++
gcc/doc/tm.texi | 6 ++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 10 ++
gcc/targhooks.c | 6 ++
gcc/targhooks.h | 2 ++
6 files changed, 40 insertions(+)
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 028013e..85f6b76 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -178,6 +178,20 @@ bpf_option_override (void)
#undef TARGET_OPTION_OVERRIDE
#define TARGET_OPTION_OVERRIDE bpf_option_override
+/* Return FALSE iff -mcore has been specified. */
+
+static bool
+ctfc_debuginfo_early_finish_p (void)
+{
+ if (TARGET_BPF_CORE)
+return false;
+ else
+return true;
+}
+
+#undef TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+#define TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P ctfc_debuginfo_early_finish_p
+
/* Define target-specific CPP macros. This function in used in the
definition of TARGET_CPU_CPP_BUILTINS in bpf.h */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index cb01528..2d5ff05 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -10400,6 +10400,12 @@ Define this macro if GCC should produce debugging
output in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@deftypefn {Target Hook} bool TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P (void)
+This target hook returns nonzero if the CTF Container can allow the
+ emission of the CTF/BTF debug info at the DWARF debuginfo early finish
+ time.
+@end deftypefn
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 4a522ae..05b3c2c 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7020,6 +7020,8 @@ Define this macro if GCC should produce debugging output
in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@hook TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/target.def b/gcc/target.def
index 68a46aa..44e2251 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -4016,6 +4016,16 @@ clobbered parts of a register altering the frame register
size",
machine_mode, (int regno),
default_dwarf_frame_reg_mode)
+/* Return nonzero if CTF Container can finalize the CTF/BTF emission
+ at DWARF debuginfo early finish time. */
+DEFHOOK
+(ctfc_debuginfo_early_finish_p,
+ "This target hook returns nonzero if the CTF Container can allow the\n\
+ emission of the CTF/BTF debug info at the DWARF
[PATCH,V2 1/3] bpf: Add new -mcore option for BPF CO-RE
-mcore in the BPF backend enables code generation for the CO-RE usecase. LTO is
disabled for CO-RE compilations.
gcc/ChangeLog:
* config/bpf/bpf.c (bpf_option_override): For BPF backend, disable LTO
support when compiling for CO-RE.
* config/bpf/bpf.opt: Add new command line option -mcore.
gcc/testsuite/ChangeLog:
* gcc.target/bpf/core-lto-1.c: New test.
---
gcc/config/bpf/bpf.c | 15 +++
gcc/config/bpf/bpf.opt| 4
gcc/testsuite/gcc.target/bpf/core-lto-1.c | 9 +
3 files changed, 28 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index e635f9e..028013e 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -158,6 +158,21 @@ bpf_option_override (void)
{
/* Set the initializer for the per-function status structure. */
init_machine_status = bpf_init_machine_status;
+
+ /* To support the portability needs of BPF CO-RE approach, BTF debug
+ information includes the BPF CO-RE relocations. The information
+ necessary for these relocations is added to the CTF container by the
+ BPF backend. Enabling LTO poses challenges in the generation of the BPF
+ CO-RE relocations because if LTO is in effect, they need to be
+ generated late in the LTO link phase. This in turn means the compiler
+ needs to provide means to combine the early and late BTF debug info,
+ similar to DWARF debug info.
+
+ In any case, in absence of linker support for BTF sections at this time,
+ it is acceptable to simply disallow LTO for BPF CO-RE compilations. */
+
+ if (flag_lto && TARGET_BPF_CORE)
+error ("BPF CO-RE does not support LTO");
}
#undef TARGET_OPTION_OVERRIDE
diff --git a/gcc/config/bpf/bpf.opt b/gcc/config/bpf/bpf.opt
index 916b53c..e8926f5 100644
--- a/gcc/config/bpf/bpf.opt
+++ b/gcc/config/bpf/bpf.opt
@@ -127,3 +127,7 @@ Generate little-endian eBPF.
mframe-limit=
Target Joined RejectNegative UInteger IntegerRange(0, 32767)
Var(bpf_frame_limit) Init(512)
Set a hard limit for the size of each stack frame, in bytes.
+
+mcore
+Target Mask(BPF_CORE)
+Generate all necessary information for BPF Compile Once - Run Everywhere.
diff --git a/gcc/testsuite/gcc.target/bpf/core-lto-1.c
b/gcc/testsuite/gcc.target/bpf/core-lto-1.c
new file mode 100644
index 000..a90dc5b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/bpf/core-lto-1.c
@@ -0,0 +1,9 @@
+/* Test -mcore with -flto.
+
+ -mcore is used to generate information for BPF CO-RE usecase. To support
+ the generataion of the .BTF and .BTF.ext sections in GCC, -flto is disabled
+ with -mcore. */
+
+/* { dg-do compile } */
+/* { dg-error "BPF CO-RE does not support LTO" "" { target bpf-*-* } 0 } */
+/* { dg-options "-gbtf -mcore -flto" } */
--
1.8.3.1
[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase
DWARF generation is split between early and late phases when LTO is in effect.
This poses challenges for CTF/BTF generation especially if late debug info
generation is desirable, as turns out to be the case for BPF CO-RE.
In case of BPF CO-RE, the BPF backend adds information about CO-RE relocations
to the CTF container. This information is what needs to be emitted as a
separate .BTF.ext section when -more is in effect. Further, each CO-RE
relocation record holds an offset to a string specifying the access to the
structure's field. This means that .BTF string table needs to be modified
"late" in the compilation process. In other words, this implies that the BTF
sections cannot be finalized in dwarf2out_early_finish when -mcore for the BPF
backend is in effect.
Now, the emission of CTF/BTF debug info cannot be moved unconditionally to
dwarf2out_finish because dwarf2out_finish is not invoked at all for the LTO
compile phase for slim LTO objects, thus breaking CTF/BTF generation for other
targets when used with LTO.
The approach taken here in this patch is that -
1. LTO is disabled for BPF CO-RE
The reason to disable LTO for BPF CO-RE is that if LTO is in effect, BPF CO-RE
relocations need to be generated in the LTO link phase _after_ the optimizations
are done. This means we need to devise way to combine early and late BTF. At
this time, in absence of linker support for BTF sections, it makes sense to
steer clear of LTO for BPF CO-RE and bypass the issue.
2. Use a target hook to allow BPF backend to cleanly convey the case when late
finalization of the CTF container is desirable.
So, in other words,
dwarf2out_early_finish
- Always emit CTF here.
- if (BTF && ctfc_debuginfo_early_finish_p), emit BTF now.
dwarf2out_finish
- if (BTF && !ctfc_debuginfo_early_finish_p && !in_lto_p) emit BTF now.
- Use of in_lto_p to make sure LTO link phase does not affect BTF sections
for other targets.
gcc/ChangeLog:
* dwarf2ctf.c (ctf_debug_finalize): Make it static.
(ctf_debug_early_finish): New definition.
(ctf_debug_finish): Likewise.
* dwarf2ctf.h (ctf_debug_finalize): Remove declaration.
(ctf_debug_early_finish): New declaration.
(ctf_debug_finish): Likewise.
* dwarf2out.c (dwarf2out_finish): Invoke ctf_debug_finish.
(dwarf2out_early_finish): Invoke ctf_debug_early_finish.
---
gcc/dwarf2ctf.c | 55 +++
gcc/dwarf2ctf.h | 4 +++-
gcc/dwarf2out.c | 9 +++--
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/gcc/dwarf2ctf.c b/gcc/dwarf2ctf.c
index 5e8a725..0fa429c 100644
--- a/gcc/dwarf2ctf.c
+++ b/gcc/dwarf2ctf.c
@@ -917,6 +917,27 @@ gen_ctf_type (ctf_container_ref ctfc, dw_die_ref die)
return type_id;
}
+/* Prepare for output and write out the CTF debug information. */
+
+static void
+ctf_debug_finalize (const char *filename, bool btf)
+{
+ if (btf)
+{
+ btf_output (filename);
+ btf_finalize ();
+}
+
+ else
+{
+ /* Emit the collected CTF information. */
+ ctf_output (filename);
+
+ /* Reset the CTF state. */
+ ctf_finalize ();
+}
+}
+
bool
ctf_do_die (dw_die_ref die)
{
@@ -966,25 +987,35 @@ ctf_debug_init_postprocess (bool btf)
btf_init_postprocess ();
}
-/* Prepare for output and write out the CTF debug information. */
+/* Early finish CTF/BTF debug info. */
void
-ctf_debug_finalize (const char *filename, bool btf)
+ctf_debug_early_finish (const char * filename)
{
- if (btf)
+ /* Emit CTF debug info early always. */
+ if (ctf_debug_info_level > CTFINFO_LEVEL_NONE
+ /* Emit BTF debug info early if the target does not require late
+emission. */
+ || (btf_debuginfo_p ()
+ && targetm.ctfc_debuginfo_early_finish_p ()))
{
- btf_output (filename);
- btf_finalize ();
+ /* Emit CTF/BTF debug info. */
+ ctf_debug_finalize (filename, btf_debuginfo_p ());
}
+}
- else
-{
- /* Emit the collected CTF information. */
- ctf_output (filename);
+/* Finish CTF/BTF debug info emission. */
- /* Reset the CTF state. */
- ctf_finalize ();
-}
+void
+ctf_debug_finish (const char * filename)
+{
+ /* Emit BTF debug info here when the target needs to update the CTF container
+ (ctfc) in the backend. An example of this, at this time is the BPF CO-RE
+ usecase. */
+ if (btf_debuginfo_p ()
+ && (!in_lto_p && !targetm.ctfc_debuginfo_early_finish_p ()))
+/* Emit BTF debug info. */
+ctf_debug_finalize (filename, btf_debuginfo_p ());
}
#include "gt-dwarf2ctf.h"
diff --git a/gcc/dwarf2ctf.h b/gcc/dwarf2ctf.h
index a3cf567..9edbde0 100644
--- a/gcc/dwarf2ctf.h
+++ b/gcc/dwarf2ctf.h
@@ -24,13 +24,15 @@ along with GCC; see the file COPYING3. If not see
#define GCC_DWARF2CTF_H 1
#include "dwarf2out.h"
+#include "flags.h"
/* Debug Format Interface. Used in dwarf2out.c. */
extern void ctf_debug_init
[PATCH, V2 2/3] targhooks: New target hook for CTF/BTF debug info emission
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
gcc/ChangeLog:
* config/bpf/bpf.c (ctfc_debuginfo_early_finish_p): New definition.
(TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P): Undefine and override.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Document the new hook.
* target.def: Add a new hook.
* targhooks.c (default_ctfc_debuginfo_early_finish_p): Likewise.
* targhooks.h (default_ctfc_debuginfo_early_finish_p): Likewise.
---
gcc/config/bpf/bpf.c | 14 ++
gcc/doc/tm.texi | 6 ++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 10 ++
gcc/targhooks.c | 6 ++
gcc/targhooks.h | 2 ++
6 files changed, 40 insertions(+)
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 028013e..85f6b76 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -178,6 +178,20 @@ bpf_option_override (void)
#undef TARGET_OPTION_OVERRIDE
#define TARGET_OPTION_OVERRIDE bpf_option_override
+/* Return FALSE iff -mcore has been specified. */
+
+static bool
+ctfc_debuginfo_early_finish_p (void)
+{
+ if (TARGET_BPF_CORE)
+return false;
+ else
+return true;
+}
+
+#undef TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+#define TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P ctfc_debuginfo_early_finish_p
+
/* Define target-specific CPP macros. This function in used in the
definition of TARGET_CPU_CPP_BUILTINS in bpf.h */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index cb01528..2d5ff05 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -10400,6 +10400,12 @@ Define this macro if GCC should produce debugging
output in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@deftypefn {Target Hook} bool TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P (void)
+This target hook returns nonzero if the CTF Container can allow the
+ emission of the CTF/BTF debug info at the DWARF debuginfo early finish
+ time.
+@end deftypefn
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 4a522ae..05b3c2c 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7020,6 +7020,8 @@ Define this macro if GCC should produce debugging output
in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@hook TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/target.def b/gcc/target.def
index 68a46aa..44e2251 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -4016,6 +4016,16 @@ clobbered parts of a register altering the frame
register size",
machine_mode, (int regno),
default_dwarf_frame_reg_mode)
+/* Return nonzero if CTF Container can finalize the CTF/BTF emission
+ at DWARF debuginfo early finish time. */
+DEFHOOK
+(ctfc_debuginfo_early_finish_p,
+ "This target hook returns nonzero if the CTF Container can allow the\n\
+ emission of the CTF/BTF debug info at the DWARF debuginfo early finish\n\
+ time.",
+ bool, (void),
+ default_ctfc_debuginfo_early_finish_p)
+
/* If expand_builtin_init_dwarf_reg_sizes needs to fill in table
entries not corresponding directly to registers below
FIRST_PSEUDO_REGISTER, this hook should generate the necessary
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index eb51909..e38566c 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -2112,6 +2112,12 @@ default_dwarf_frame_reg_mode (int regno)
return save_mode;
}
+bool
+default_ctfc_debuginfo_early_finish_p (void)
+{
+ return true;
+}
+
/* To be used by targets where reg_raw_mode doesn't return the right
mode for registers used in apply_builtin_return and apply_builtin_arg. */
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index f92e102..55dc443 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -255,6 +255,8 @@ extern unsigned int default_dwarf_poly_indeterminate_value
(unsigned int,
unsigned int *,
int *);
extern machine_mode default_dwarf_frame_reg_mode (int);
+extern bool default_ctfc_debuginfo_early_finish_p (void);
+
extern fixed_size_mode default_get_reg_raw_mode (int);
extern bool default_keep_leaf_when_profiled ();
--
1.8.3.1
[PATCH,V2 0/3] Allow means for late BTF generation for BPF CO-RE
[Changes from V1] - [1/3] bpf: Add new -mcore option for BPF CO-RE Moved the testcase from gcc.dg/debug/btf/ to gcc.target/bpf/. Adjusted the testcase a bit. - targhooks: New target hook for CTF/BTF debug info emission (Same as V1) - dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase Moved the call to ctf_debug_finish (in dwarf2out_finish) before the point of early exit taken when dwarf_debuginfo_p () is false. [End of Changes from V1] Hello, This patch series puts the framework in place for late BTF generation (in dwarf2out_finish). This is needed for the landing of BPF CO-RE support in GCC, patches for which were posted recently https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576719.html. BPF's Compile Once - Run Everywhere (CO-RE) feature is used to make a compiled BPF program portable across kernel versions, all this without the need to recompile the BPF program. A key part of BPF CO-RE capability is the BTF debug info generated for them. A traditional BPF program (non CO-RE) will have a .BTF section which contains the type information in the BTF debug format. In case of CO-RE, however, an additional section .BTF.ext section is generated. The .BTF.ext section contains the CO-RE relocations. A BPF loader will use the .BTF.ext section along with the associated .BTF.ext section to adjust some references in the instructions of program to ensure it is compatible with the required kernel version / headers. Roughly, each CO-RE relocation record will contain the following info - offset of BPF instruction to be patched - the BTF ID of the data structure being accessed by the instruction, and - an offset to the BTF string which encodes a series of field accesses to retrieve the field of interest in the instruction. High-level design - - The CTF container is populated with the compiler-internal representation for the "type information" at dwarf2out_early_finish time. - In case of CO-RE compilation, the information needed to generate .BTF.ext section is added by the BPF backend to the CTF container (CTFC) at XXX time. This introduces challenges in having LTO support for CO-RE - CO-RE relocations can only be generated late, much like late DWARF. - Combining late and early BTF is not being done as the patch set disables LTO to be used together with CO-RE for the BPF target. - A new target hook is added for the CTFC (CTF Container) to know whether early emission of CTF/BTF is allowed for the target. Testing Notes - Bootstrapped and reg tested on x86_64 - make all-gcc for --target=bpf-unknown-none; tested ctf.exp, btf.exp and bpf.exp Thanks, Indu Bhagat (3): bpf: Add new -mcore option for BPF CO-RE targhooks: New target hook for CTF/BTF debug info emission dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase gcc/config/bpf/bpf.c | 29 gcc/config/bpf/bpf.opt| 4 +++ gcc/doc/tm.texi | 6 gcc/doc/tm.texi.in| 2 ++ gcc/dwarf2ctf.c | 55 --- gcc/dwarf2ctf.h | 4 ++- gcc/dwarf2out.c | 9 +++-- gcc/target.def| 10 ++ gcc/targhooks.c | 6 gcc/targhooks.h | 2 ++ gcc/testsuite/gcc.target/bpf/core-lto-1.c | 9 + 11 files changed, 121 insertions(+), 15 deletions(-) create mode 100644 gcc/testsuite/gcc.target/bpf/core-lto-1.c -- 1.8.3.1
[PATCH 2/3] targhooks: New target hook for CTF/BTF debug info emission
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debug is
finalized (dwarf2out_finish).
gcc/ChangeLog:
* config/bpf/bpf.c (ctfc_debuginfo_early_finish_p): New definition.
(TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P): Undefine and override.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Document the new hook.
* target.def: Add a new hook.
* targhooks.c (default_ctfc_debuginfo_early_finish_p): Likewise.
* targhooks.h (default_ctfc_debuginfo_early_finish_p): Likewise.
---
gcc/config/bpf/bpf.c | 14 ++
gcc/doc/tm.texi | 6 ++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 10 ++
gcc/targhooks.c | 6 ++
gcc/targhooks.h | 2 ++
6 files changed, 40 insertions(+)
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 028013e..85f6b76 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -178,6 +178,20 @@ bpf_option_override (void)
#undef TARGET_OPTION_OVERRIDE
#define TARGET_OPTION_OVERRIDE bpf_option_override
+/* Return FALSE iff -mcore has been specified. */
+
+static bool
+ctfc_debuginfo_early_finish_p (void)
+{
+ if (TARGET_BPF_CORE)
+return false;
+ else
+return true;
+}
+
+#undef TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+#define TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P ctfc_debuginfo_early_finish_p
+
/* Define target-specific CPP macros. This function in used in the
definition of TARGET_CPU_CPP_BUILTINS in bpf.h */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a464d26..df408ee 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -10400,6 +10400,12 @@ Define this macro if GCC should produce debugging
output in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@deftypefn {Target Hook} bool TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P (void)
+This target hook returns nonzero if the CTF Container can allow the
+ emission of the CTF/BTF debug info at the DWARF debuginfo early finish
+ time.
+@end deftypefn
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 0b60342..6119a30 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7020,6 +7020,8 @@ Define this macro if GCC should produce debugging output
in BTF debug
format in response to the @option{-gbtf} option.
@end defmac
+@hook TARGET_CTFC_DEBUGINFO_EARLY_FINISH_P
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/target.def b/gcc/target.def
index 6b4226c..67bdcba 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -4007,6 +4007,16 @@ clobbered parts of a register altering the frame
register size",
machine_mode, (int regno),
default_dwarf_frame_reg_mode)
+/* Return nonzero if CTF Container can finalize the CTF/BTF emission
+ at DWARF debuginfo early finish time. */
+DEFHOOK
+(ctfc_debuginfo_early_finish_p,
+ "This target hook returns nonzero if the CTF Container can allow the\n\
+ emission of the CTF/BTF debug info at the DWARF debuginfo early finish\n\
+ time.",
+ bool, (void),
+ default_ctfc_debuginfo_early_finish_p)
+
/* If expand_builtin_init_dwarf_reg_sizes needs to fill in table
entries not corresponding directly to registers below
FIRST_PSEUDO_REGISTER, this hook should generate the necessary
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index eb51909..e38566c 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -2112,6 +2112,12 @@ default_dwarf_frame_reg_mode (int regno)
return save_mode;
}
+bool
+default_ctfc_debuginfo_early_finish_p (void)
+{
+ return true;
+}
+
/* To be used by targets where reg_raw_mode doesn't return the right
mode for registers used in apply_builtin_return and apply_builtin_arg. */
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index f92e102..55dc443 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -255,6 +255,8 @@ extern unsigned int default_dwarf_poly_indeterminate_value
(unsigned int,
unsigned int *,
int *);
extern machine_mode default_dwarf_frame_reg_mode (int);
+extern bool default_ctfc_debuginfo_early_finish_p (void);
+
extern fixed_size_mode default_get_reg_raw_mode (int);
extern bool default_keep_leaf_when_profiled ();
--
1.8.3.1
[PATCH 1/3] bpf: Add new -mcore option for BPF CO-RE
-mcore in the BPF backend enables code generation for the CO-RE usecase. LTO is
disabled for CO-RE compilations.
gcc/ChangeLog:
* config/bpf/bpf.c (bpf_option_override): For BPF backend, disable LTO
support when compiling for CO-RE.
* config/bpf/bpf.opt: Add new command line option -mcore.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-mcore-1.c: New test.
---
gcc/config/bpf/bpf.c | 15 +++
gcc/config/bpf/bpf.opt | 4
gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c | 14 ++
3 files changed, 33 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index e635f9e..028013e 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -158,6 +158,21 @@ bpf_option_override (void)
{
/* Set the initializer for the per-function status structure. */
init_machine_status = bpf_init_machine_status;
+
+ /* To support the portability needs of BPF CO-RE approach, BTF debug
+ information includes the BPF CO-RE relocations. The information
+ necessary for these relocations is added to the CTF container by the
+ BPF backend. Enabling LTO poses challenges in the generation of the BPF
+ CO-RE relocations because if LTO is in effect, they need to be
+ generated late in the LTO link phase. This in turn means the compiler
+ needs to provide means to combine the early and late BTF debug info,
+ similar to DWARF debug info.
+
+ In any case, in absence of linker support for BTF sections at this time,
+ it is acceptable to simply disallow LTO for BPF CO-RE compilations. */
+
+ if (flag_lto && TARGET_BPF_CORE)
+error ("BPF CO-RE does not support LTO");
}
#undef TARGET_OPTION_OVERRIDE
diff --git a/gcc/config/bpf/bpf.opt b/gcc/config/bpf/bpf.opt
index 916b53c..e8926f5 100644
--- a/gcc/config/bpf/bpf.opt
+++ b/gcc/config/bpf/bpf.opt
@@ -127,3 +127,7 @@ Generate little-endian eBPF.
mframe-limit=
Target Joined RejectNegative UInteger IntegerRange(0, 32767)
Var(bpf_frame_limit) Init(512)
Set a hard limit for the size of each stack frame, in bytes.
+
+mcore
+Target Mask(BPF_CORE)
+Generate all necessary information for BPF Compile Once - Run Everywhere.
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c
new file mode 100644
index 000..58f20d0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c
@@ -0,0 +1,14 @@
+/* Testcase for BPF CO-RE.
+
+ -mcore is used to generate information for BPF CO-RE usecase. To support
+ the generataion of the .BTF and .BTF.ext sections in GCC, -flto is disabled
+ with -mcore. */
+
+/* { dg-do compile { target bpf-*-* } } */
+/* { dg-error "BPF CO-RE does not support LTO" "" { target btf-*-* } 0 } */
+
+/* { dg-require-effective-target lto } */
+
+/* { dg-options "-gbtf -mcore -flto" } */
+
+void func(void) { }
--
1.8.3.1
[PATCH 0/3] Allow means for late BTF generation for BPF CO-RE
Hello, This patch series puts the framework in place for late BTF generation (in dwarf2out_finish). This is needed for the landing of BPF CO-RE support in GCC. BPF's Compile Once - Run Everywhere (CO-RE) feature is used to make a compiled BPF program portable across kernel versions, all this without the need to recompile the BPF program. A key part of BPF CO-RE capability is the BTF debug info generated for the BPF program. A traditional BPF program (non CO-RE) will have a .BTF section which contains the type information in the BTF debug format. In case of CO-RE, however, an additional section .BTF.ext section is generated. The .BTF.ext section contains the CO-RE relocations. A BPF loader will use the .BTF.ext section along with the associated .BTF section to adjust some references in the instructions of the BPF program to ensure it is compatible with the required kernel version / headers. Roughly, each CO-RE relocation record will contain the following info: - offset of BPF instruction to be patched, - the BTF ID of the data structure being accessed by the instruction, and - an offset to the BTF string which encodes a series of field accesses to retrieve the field of interest in the instruction. High-level design - - The CTF container (CTFC) is populated with the compiler-internal representation for the CTF/BTF "type information" at dwarf2out_early_finish time. - In case of CO-RE compilation, the information needed to generate .BTF.ext section will be added by the BPF backend to the CTF container (CTFC) at expand time. This introduces challenges in having LTO support for CO-RE - CO-RE relocations can only be generated late in the compilation process, much like late DWARF. - While .BTF.ext is a separate section, the format requires that the string encodings of field accesses (in the CO-RE relocation record) are added in the .BTF string table. Recall that .BTF strings are owned by the .BTF section. Hence, this means that .BTF section cannot simply be emitted "early" because the CO-RE relocations records will need to add additional .BTF strings to the .BTF section. - This patch set disables LTO to be used together with CO-RE for the BPF target. Combining late and early BTF is not being done in this patch series. BTF debug info emission for CO-RE compilations is done at dwarf2out_finish time. - A new target hook is added for the CTFC (CTF Container) to know whether early emission of CTF/BTF is allowed for the target. The hook returns false when "-mcore" for the BPF target is in effect. Testing notes - - Bootstrapped and reg tested (make check-gcc) on x86_64-pc-linux. - make all-gcc for --target=bpf-unknown-none. Thanks, Indu Bhagat (3): bpf: Add new -mcore option for BPF CO-RE targhooks: New target hook for CTF/BTF debug info emission dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase gcc/config/bpf/bpf.c | 29 +++ gcc/config/bpf/bpf.opt | 4 ++ gcc/doc/tm.texi | 6 +++ gcc/doc/tm.texi.in | 2 + gcc/dwarf2ctf.c | 55 ++-- gcc/dwarf2ctf.h | 4 +- gcc/dwarf2out.c | 9 - gcc/target.def | 10 + gcc/targhooks.c | 6 +++ gcc/targhooks.h | 2 + gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c | 14 +++ 11 files changed, 126 insertions(+), 15 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-mcore-1.c -- 1.8.3.1
[PATCH 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE usecase
DWARF generation is split between early and late phases when LTO is in effect.
This poses challenges for CTF/BTF generation especially if late debug info
generation is desirable, as turns out to be the case for BPF CO-RE.
In case of BPF CO-RE, the BPF backend adds information about CO-RE relocations
to the CTF container. This information is what needs to be emitted as a
separate .BTF.ext section when -more is in effect. Further, each CO-RE
relocation record holds an offset to a string specifying the access to the
structure's field. This means that .BTF string table needs to be modified
"late" in the compilation process. In other words, this implies that the BTF
sections cannot be finalized in dwarf2out_early_finish when -mcore for the BPF
backend is in effect.
Now, the emission of CTF/BTF debug info cannot be moved unconditionally to
dwarf2out_finish because dwarf2out_finish is not invoked at all for the LTO
compile phase for slim LTO objects, thus breaking CTF/BTF generation for other
targets when used with LTO.
The approach taken here in this patch is that -
1. LTO is disabled for BPF CO-RE
The reason to disable LTO for BPF CO-RE is that if LTO is in effect, BPF CO-RE
relocations need to be generated in the LTO link phase _after_ the optimizations
are done. This means we need to devise way to combine early and late BTF. At
this time, in absence of linker support for BTF sections, it makes sense to
steer clear of LTO for BPF CO-RE and bypass the issue.
2. Use a target hook to allow BPF backend to cleanly convey the case when late
finalization of the CTF container is desirable.
So, in other words,
dwarf2out_early_finish
- Always emit CTF here.
- if (BTF && ctfc_debuginfo_early_finish_p), emit BTF now.
dwarf2out_finish
- if (BTF && !ctfc_debuginfo_early_finish_p && !in_lto_p) emit BTF now.
- Use of in_lto_p to make sure LTO link phase does not affect BTF sections
for other targets.
gcc/ChangeLog:
* dwarf2ctf.c (ctf_debug_finalize): Make it static.
(ctf_debug_early_finish): New definition.
(ctf_debug_finish): Likewise.
* dwarf2ctf.h (ctf_debug_finalize): Remove declaration.
(ctf_debug_early_finish): New declaration.
(ctf_debug_finish): Likewise.
* dwarf2out.c (dwarf2out_finish): Invoke ctf_debug_finish.
(dwarf2out_early_finish): Invoke ctf_debug_early_finish.
---
gcc/dwarf2ctf.c | 55 +++
gcc/dwarf2ctf.h | 4 +++-
gcc/dwarf2out.c | 9 +++--
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/gcc/dwarf2ctf.c b/gcc/dwarf2ctf.c
index 5e8a725..0fa429c 100644
--- a/gcc/dwarf2ctf.c
+++ b/gcc/dwarf2ctf.c
@@ -917,6 +917,27 @@ gen_ctf_type (ctf_container_ref ctfc, dw_die_ref die)
return type_id;
}
+/* Prepare for output and write out the CTF debug information. */
+
+static void
+ctf_debug_finalize (const char *filename, bool btf)
+{
+ if (btf)
+{
+ btf_output (filename);
+ btf_finalize ();
+}
+
+ else
+{
+ /* Emit the collected CTF information. */
+ ctf_output (filename);
+
+ /* Reset the CTF state. */
+ ctf_finalize ();
+}
+}
+
bool
ctf_do_die (dw_die_ref die)
{
@@ -966,25 +987,35 @@ ctf_debug_init_postprocess (bool btf)
btf_init_postprocess ();
}
-/* Prepare for output and write out the CTF debug information. */
+/* Early finish CTF/BTF debug info. */
void
-ctf_debug_finalize (const char *filename, bool btf)
+ctf_debug_early_finish (const char * filename)
{
- if (btf)
+ /* Emit CTF debug info early always. */
+ if (ctf_debug_info_level > CTFINFO_LEVEL_NONE
+ /* Emit BTF debug info early if the target does not require late
+emission. */
+ || (btf_debuginfo_p ()
+ && targetm.ctfc_debuginfo_early_finish_p ()))
{
- btf_output (filename);
- btf_finalize ();
+ /* Emit CTF/BTF debug info. */
+ ctf_debug_finalize (filename, btf_debuginfo_p ());
}
+}
- else
-{
- /* Emit the collected CTF information. */
- ctf_output (filename);
+/* Finish CTF/BTF debug info emission. */
- /* Reset the CTF state. */
- ctf_finalize ();
-}
+void
+ctf_debug_finish (const char * filename)
+{
+ /* Emit BTF debug info here when the target needs to update the CTF container
+ (ctfc) in the backend. An example of this, at this time is the BPF CO-RE
+ usecase. */
+ if (btf_debuginfo_p ()
+ && (!in_lto_p && !targetm.ctfc_debuginfo_early_finish_p ()))
+/* Emit BTF debug info. */
+ctf_debug_finalize (filename, btf_debuginfo_p ());
}
#include "gt-dwarf2ctf.h"
diff --git a/gcc/dwarf2ctf.h b/gcc/dwarf2ctf.h
index a3cf567..9edbde0 100644
--- a/gcc/dwarf2ctf.h
+++ b/gcc/dwarf2ctf.h
@@ -24,13 +24,15 @@ along with GCC; see the file COPYING3. If not see
#define GCC_DWARF2CTF_H 1
#include "dwarf2out.h"
+#include "flags.h"
/* Debug Format Interface. Used in dwarf2out.c. */
extern void ctf_debug_init
Re: Clarification on CTF/BTF workings with LTO
On 7/21/21 11:18 PM, Richard Biener wrote: On Wed, 21 Jul 2021, Indu Bhagat wrote: Hello, Wanted to follow up on the CTF/BTF debug info + LTO workings. To summarize, the current status/workflow on trunk is: - The CTF container is written out in the ctfout.c or btfout.c via the ctf_debug_finalize () API. - At this time, the ctf_debug_finalize () itself is called once in dwarf2out_early_finish (). - Until this time, the requirements of CTF and BTF are simple. - The generated .ctf/.BTF sections needs no demarcation of "early"/"late" debug. All of it can be generated "early". - The generated .ctf/.BTF information does not need to be different for the final assembly and the fat LTO IR. - The BPF CO-RE is not yet implemented on trunk. Writing out the CTF/BTF at dwarf2out_early_finish seems to work - there will always be a .ctf/.BTF section whether it's fat or slim LTO objects (because the emission is still in dwarf2out_early_finish on the trunk). And we have functionality to copy over the .ctf/.BTF debug sections in handle_lto_debug_sections (). However, reading through some of the past emails on the CTF/BTF patch series, it seems that you have been pointing to the CTF/BTF debug info generation being broken when used with LTO. If true, I am most certainly missing some key point here. So, before we move to the next steps of supporting additional requirements of BPF CO-RE etc., I would like to make sure that my current understanding is OK and that the current state of CTF/BTF on trunk is functional -with LTO-. I have tested some bits (with and without fat objects on x86_64) and have not run into issues. Can you please confirm what you see amiss in the current workings of CTF/BTF with LTO on trunk ? So on the functional level it seems to do something, that is, I see .ctf sections in a LTO linked test program as well as in a non-LTO linked program from fat LTO objects. When I dump the .ctf section with readelf I see type info that looks OK but I don't see any function objects (my test has a main and foo function). It might be an artifact of the readelf version I have (2.36.1) since the same happens w/o LTO. So yes, in principle it should work in case there's only info that needs to be emitted early. ISTR that in the beginning you had pieces emitted from dwarf2out_finish and there my concerns were rooted. For DWARF the "late" data (like anything that needs relocations to symbols or addresses) is emitted from dwarf2out_finish and the LTRANS unit where the info is emitted from does not have the DWARF DIE generated early in memory but instead it knows how to reference it by a symbol + offset relocation. So it generates a DIE like DW_TAG_subprogram DW_AT_abstract_origin $early_debug_symbol + offset DW_AT_low_pc .LC0_begin ... to amend the early DIE with additional information, creating the "concrete" instance of the subprogram, re-using the early generated DIE as "abstract" instance. I understand that CTF doesn't work like this (have relocations or DIE offsets or some such) but you need some late annotation at least for BPF? Correct. At this time, CTF does not have any relocations, or any "late" debug info. And with regards to BTF, there are two usecases that BTF is serving and each have different requirements: - [#1] BTF for any backend (including BPF _but_ excluding BPF CO-RE usecase): This just needs the .BTF section. This is currently being generated at dwarf2out_early_finish just like .ctf - [#2] BTF for the _CO-RE_usecase_of BPF backend: This will be invoked explicitly, by say -mcore, for BPF backend and the generated BTF debug info will include additional .BTF.ext section. This .BTF.ext section contains "CO-RE Relocation" records, each containing offset of BPF instruction to be patched, the BTF type ID of the data structure being accessed by the instruction, and an offset to the BTF string which encodes a series of field accesses to retrieve the field of interest in the instruction. A BPF program loader will use this .BTF.ext along with the associated .BTF and make the necessary changes to facilitate the BPF program to run across kernel versions and headers. More details on this when the patch set for BPF's CO-RE support is posted... So, yes, it is the #2 - BTF generated for CO-RE (Compile Once - Run Everywhere) usecase of BPF which needs bits to be emitted from dwarf2out_finish. The approach to best deal with this requirement is still in the works at this time. Thanks Indu
Clarification on CTF/BTF workings with LTO
Hello, Wanted to follow up on the CTF/BTF debug info + LTO workings. To summarize, the current status/workflow on trunk is: - The CTF container is written out in the ctfout.c or btfout.c via the ctf_debug_finalize () API. - At this time, the ctf_debug_finalize () itself is called once in dwarf2out_early_finish (). - Until this time, the requirements of CTF and BTF are simple. - The generated .ctf/.BTF sections needs no demarcation of "early"/"late" debug. All of it can be generated "early". - The generated .ctf/.BTF information does not need to be different for the final assembly and the fat LTO IR. - The BPF CO-RE is not yet implemented on trunk. Writing out the CTF/BTF at dwarf2out_early_finish seems to work - there will always be a .ctf/.BTF section whether it's fat or slim LTO objects (because the emission is still in dwarf2out_early_finish on the trunk). And we have functionality to copy over the .ctf/.BTF debug sections in handle_lto_debug_sections (). However, reading through some of the past emails on the CTF/BTF patch series, it seems that you have been pointing to the CTF/BTF debug info generation being broken when used with LTO. If true, I am most certainly missing some key point here. So, before we move to the next steps of supporting additional requirements of BPF CO-RE etc., I would like to make sure that my current understanding is OK and that the current state of CTF/BTF on trunk is functional -with LTO-. I have tested some bits (with and without fat objects on x86_64) and have not run into issues. Can you please confirm what you see amiss in the current workings of CTF/BTF with LTO on trunk ? Thanks Indu
[PATCH 2/2] debug: Allow means for targets to opt out of CTF/BTF support
CTF/BTF debug formats can be safely enabled for all ELF-based targets by
default in GCC.
CTF/BTF debug formats now adopt a similar approach as taken for DWARF debug
format via the DWARF2_DEBUGGING_INFO.
- By default, CTF/BTF formats can be enabled for all ELF-based targets.
- By default, CTF/BTF formats can be disabled for all non ELF-based targets.
- If the user passed a -gctf but CTF is not enabled for the target, GCC
issues an error to the user (as is done currently with other debug formats) -
"target system does not support the 'ctf' debug format". Analogous behavior
for -gbtf command line option.
A previous commit disabled the CTF and BTF testcases on the AIX platform. This
is not necessary now that CTF and BTF debug formats are disabled by default on
all non-ELF targets. GCC emits an error message when -gctf/-gbtf is used on
such platforms and these tests will be skipped.
gcc/Changelog:
* config/elfos.h (CTF_DEBUGGING_INFO): New definition.
(BTF_DEBUGGING_INFO): Likewise.
* doc/tm.texi.in: Document the new macros.
* doc/tm.texi: Regenerated.
* toplev.c: Guard initialization of debug hooks.
gcc/testsuite/Changelog:
* gcc.dg/debug/btf/btf.exp: Do not run BTF testsuite if target does not
support BTF format. Remove redundant check for AIX.
* gcc.dg/debug/ctf/ctf.exp: Do not run CTF testsuite if target does not
support CTF format. Remove redundant check for AIX.
* lib/gcc-dg.exp: Remove redundant check for AIX.
---
gcc/config/elfos.h | 8
gcc/doc/tm.texi| 26 ++
gcc/doc/tm.texi.in | 26 ++
gcc/testsuite/gcc.dg/debug/btf/btf.exp | 16 +---
gcc/testsuite/gcc.dg/debug/ctf/ctf.exp | 16 +---
gcc/testsuite/lib/gcc-dg.exp | 1 -
gcc/toplev.c | 11 +--
7 files changed, 87 insertions(+), 17 deletions(-)
diff --git a/gcc/config/elfos.h b/gcc/config/elfos.h
index 7a736cc..e5cb487 100644
--- a/gcc/config/elfos.h
+++ b/gcc/config/elfos.h
@@ -68,6 +68,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#define DWARF2_DEBUGGING_INFO 1
+/* All ELF targets can support CTF. */
+
+#define CTF_DEBUGGING_INFO 1
+
+/* All ELF targets can support BTF. */
+
+#define BTF_DEBUGGING_INFO 1
+
/* The GNU tools operate better with dwarf2, and it is required by some
psABI's. Since we don't have any native tools to be compatible with,
default to dwarf2. */
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 3ad3944..c8f4abe 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -9947,6 +9947,8 @@ This describes how to specify debugging information.
* File Names and DBX:: Macros controlling output of file names in DBX format.
* DWARF:: Macros for DWARF format.
* VMS Debug:: Macros for VMS debug format.
+* CTF Debug:: Macros for CTF debug format.
+* BTF Debug:: Macros for BTF debug format.
@end menu
@node All Debuggers
@@ -10374,6 +10376,30 @@ behavior is controlled by
@code{TARGET_OPTION_OPTIMIZATION} and
@code{TARGET_OPTION_OVERRIDE}.
@end defmac
+@need 2000
+@node CTF Debug
+@subsection Macros for CTF Debug Format
+
+@c prevent bad page break with this line
+Here are macros for CTF debug format.
+
+@defmac CTF_DEBUGGING_INFO
+Define this macro if GCC should produce debugging output in CTF debug
+format in response to the @option{-gctf} option.
+@end defmac
+
+@need 2000
+@node BTF Debug
+@subsection Macros for BTF Debug Format
+
+@c prevent bad page break with this line
+Here are macros for BTF debug format.
+
+@defmac BTF_DEBUGGING_INFO
+Define this macro if GCC should produce debugging output in BTF debug
+format in response to the @option{-gbtf} option.
+@end defmac
+
@node Floating Point
@section Cross Compilation and Floating Point
@cindex cross compilation and floating point
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index f881cda..9c4b501 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -6613,6 +6613,8 @@ This describes how to specify debugging information.
* File Names and DBX:: Macros controlling output of file names in DBX format.
* DWARF:: Macros for DWARF format.
* VMS Debug:: Macros for VMS debug format.
+* CTF Debug:: Macros for CTF debug format.
+* BTF Debug:: Macros for BTF debug format.
@end menu
@node All Debuggers
@@ -6994,6 +6996,30 @@ behavior is controlled by
@code{TARGET_OPTION_OPTIMIZATION} and
@code{TARGET_OPTION_OVERRIDE}.
@end defmac
+@need 2000
+@node CTF Debug
+@subsection Macros for CTF Debug Format
+
+@c prevent bad page break with this line
+Here are macros for CTF debug format.
+
+@defmac CTF_DEBUGGING_INFO
+Define this macro if GCC should produce debugging output in CTF debug
+format in response to the @option{-gctf} option.
+@end defmac
+
+@need 2
[PATCH 1/2] debug: Add new function ctf_debuginfo_p
gcc/Changelog:
* flags.h (ctf_debuginfo_p): New function declaration.
* opts.c (ctf_debuginfo_p): New function definition.
---
gcc/flags.h | 4
gcc/opts.c | 8
2 files changed, 12 insertions(+)
diff --git a/gcc/flags.h b/gcc/flags.h
index 85fd228..afedef0 100644
--- a/gcc/flags.h
+++ b/gcc/flags.h
@@ -44,6 +44,10 @@ const char * debug_set_names (uint32_t w_symbols);
extern bool btf_debuginfo_p ();
+/* Return true iff CTF debug info is enabled. */
+
+extern bool ctf_debuginfo_p ();
+
/* Return true iff DWARF2 debug info is enabled. */
extern bool dwarf_debuginfo_p ();
diff --git a/gcc/opts.c b/gcc/opts.c
index 25282f7..93366e6 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -135,6 +135,14 @@ btf_debuginfo_p ()
return (write_symbols & BTF_DEBUG);
}
+/* Return TRUE iff CTF debug info is enabled. */
+
+bool
+ctf_debuginfo_p ()
+{
+ return (write_symbols & CTF_DEBUG);
+}
+
/* Return TRUE iff dwarf2 debug info is enabled. */
bool
--
1.8.3.1
[PATCH 0/2] Allow means for targets to opt out of CTF/BTF
Hello, Thanks for your feedback on the previous RFC version of this proposal. This patch set is a refined and tested version of the same. - Added changes to tm.texi.in and regenerated tm.texi. - Updated the dejagnu files for redundant checks on AIX platform. Bootstrapped and reg tested on x86_64-pc-linux-gnu and powerpc-ibm-aix7.2.4.0. Thanks, Indu Bhagat (2): debug: Add new function ctf_debuginfo_p debug: Allow means for targets to opt out of CTF/BTF support gcc/config/elfos.h | 8 gcc/doc/tm.texi| 26 ++ gcc/doc/tm.texi.in | 26 ++ gcc/flags.h| 4 gcc/opts.c | 8 gcc/testsuite/gcc.dg/debug/btf/btf.exp | 16 +--- gcc/testsuite/gcc.dg/debug/ctf/ctf.exp | 16 +--- gcc/testsuite/lib/gcc-dg.exp | 1 - gcc/toplev.c | 11 +-- 9 files changed, 99 insertions(+), 17 deletions(-) -- 1.8.3.1
[RFC,PATCH] Allow means for targets to out out of CTF/BTF support
Hello,
It was brought up when discussing PR debug/101283 (Several tests fail on
Darwin with -gctf/gbtf) that it will be good to provide means for targets to
opt out of CTF/BTF support.
By and large, it seems to me that CTF/BTF debug formats can be safely enabled
for all ELF-based targets by default in GCC.
So, at a high level:
- By default, CTF/BTF formats can be enabled for all ELF-based targets.
- By default, CTF/BTF formats can be disabled for all non ELF-based targets.
- If the user passed a -gctf but CTF is not enabled for the target, GCC
issues an error to the user (as is done currently with other debug formats) -
"target system does not support the 'ctf' debug format".
This is a makeshift patch which fulfills the above requirements and is based on
the approach taken for DWARF via DWARF2_DEBUGGING_INFO (I still have to see if
I need some specific handling in common_handle_option in opts.c). On minimal
testing, the patch works as desired on x86_64-pc-linux-gnu and a darwin-based
target.
My question is - Looking around in config.gcc etc., it seems defining in elfos.h
gives targets/platforms means to override it by virtue of the recommended order
of # includes in $tm_file. What I cannot say for certain is if this is true in
practice ? On first look, I believe this could work fine. What do you think ?
If you think this approach could work, I will continue on this track and
test/refine the patch.
Thanks
Indu
-
gcc/ChangeLog:
* config/elfos.h (CTF_DEBUGGING_INFO): New definition.
(BTF_DEBUGGING_INFO): Likewise.
* toplev.c: Guard initialization of debug hooks.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf.exp: Do not run BTF testsuite if target does not
support BTF format.
* gcc.dg/debug/ctf/ctf.exp: Do not run CTF testsuite if target does not
support CTF format.
---
gcc/config/elfos.h | 8
gcc/testsuite/gcc.dg/debug/btf/btf.exp | 11 +--
gcc/testsuite/gcc.dg/debug/ctf/ctf.exp | 11 +--
gcc/toplev.c | 11 +--
4 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/gcc/config/elfos.h b/gcc/config/elfos.h
index 7a736cc..e5cb487 100644
--- a/gcc/config/elfos.h
+++ b/gcc/config/elfos.h
@@ -68,6 +68,14 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#define DWARF2_DEBUGGING_INFO 1
+/* All ELF targets can support CTF. */
+
+#define CTF_DEBUGGING_INFO 1
+
+/* All ELF targets can support BTF. */
+
+#define BTF_DEBUGGING_INFO 1
+
/* The GNU tools operate better with dwarf2, and it is required by some
psABI's. Since we don't have any native tools to be compatible with,
default to dwarf2. */
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf.exp
b/gcc/testsuite/gcc.dg/debug/btf/btf.exp
index e173515..a3e680c 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf.exp
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf.exp
@@ -39,8 +39,15 @@ if ![info exists DEFAULT_CFLAGS] then {
dg-init
# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\] ]] \
- "" $DEFAULT_CFLAGS
+set comp_output [gcc_target_compile \
+"$srcdir/$subdir/../trivial.c" "trivial.S" assembly \
+"additional_flags=-gbtf"]
+if { ! [string match "*: target system does not support the * debug format*" \
+$comp_output] } {
+remove-build-file "trivial.S"
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\] ]] \
+ "" $DEFAULT_CFLAGS
+}
# All done.
dg-finish
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf.exp
b/gcc/testsuite/gcc.dg/debug/ctf/ctf.exp
index 0b650ed..c53cd8b 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf.exp
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf.exp
@@ -39,8 +39,15 @@ if ![info exists DEFAULT_CFLAGS] then {
dg-init
# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\] ]] \
- "" $DEFAULT_CFLAGS
+set comp_output [gcc_target_compile \
+"$srcdir/$subdir/../trivial.c" "trivial.S" assembly \
+"additional_flags=-gctf"]
+if { ! [string match "*: target system does not support the * debug format*" \
+$comp_output] } {
+remove-build-file "trivial.S"
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\] ]] \
+ "" $DEFAULT_CFLAGS
+}
# All done.
dg-finish
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 43f1f7d..8103812 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1463,8 +1463,15 @@ process_options (void)
debug_hooks = &xcoff_debug_hooks;
#endif
#ifdef DWARF2_DEBUGGING_INFO
- else if (dwarf_debuginfo_p ()
- || dwarf_based_debuginfo_p ())
+ else if (dwarf_debuginfo_p ())
+debug_hooks = &dwarf2_debug_hooks;
+#endif
+#ifdef CTF_DEBUGGING_INFO
+ else if (write_symbols & CTF_DEBUG)
+debug_hooks = &dwarf2_debug_hooks;
+#endif
+#ifdef BTF_DEBUGGING_INFO
+ else if (btf_debuginfo_p ())
debug_hooks = &dwarf2_debug_hooks;
#endif
#ifdef VMS_DEBUGGING_INFO
--
1.8.3.1
[COMMITTED] BTF testsuite: Remove explicit check on btm_type
[Committed as obvious.]
The value of btm_type is the BTF type ID of the referred type. The order in
which the BTF types are added can change across platforms and also as the code
evolves, hence changing the BTF type ID. As there is no direct and portable
method of testing that a BTF type refers to another BTF type of a specific
kind, remove the explicit check on btm_type.
This patch adjusts the testcase without affecting the test coverage as other
testcases already have similar constructs. It also fixes a subset of failures
as seen on Darwin.
2021-07-06 Indu Bhagat
gcc/testsuite/ChangeLog:
PR debug/101283
* gcc.dg/debug/btf/btf-bitfields-3.c: Remove the check on btm_type.
---
gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-3.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-3.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-3.c
index 5e68416..0e00f2b 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-3.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-3.c
@@ -11,7 +11,6 @@
[2] int 'unsigned int' size=4 offset=0 bits=32
[3] struct 'bitt' size=4
member 'f' type=1 bitfield_size=2 bit_offset=0
- member 'data' type=2 bitfield_size=14 bit_offset=2
*/
/* { dg-do compile } */
@@ -19,15 +18,12 @@
/* Enum with 4 members. */
/* { dg-final { scan-assembler-times "\[\t \]0x604\[\t
\]+\[^\n\]*btt_info" 1 } } */
-/* Struct with bitfield members, and 2 members. */
-/* { dg-final { scan-assembler-times "\[\t \]0x8402\[\t
\]+\[^\n\]*btt_info" 1 } } */
+/* Struct with 1 bitfield member. */
+/* { dg-final { scan-assembler-times "\[\t \]0x8401\[\t
\]+\[^\n\]*btt_info" 1 } } */
/* Bitfield "f" points to type ID 1. */
/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btm_type" 1 }
} */
-/* Bitfield "data" points to type ID 2. */
-/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btm_type" 1 }
} */
-
enum foo
{
BAR = 0,
@@ -39,5 +35,4 @@ enum foo
struct bitt
{
enum foo f : 2;
- unsigned data : 14;
} bitty;
--
1.8.3.1
[COMMITTED] CTF testsuite: Remove explicit check on ctv_typeidx
[Committed as obvious.]
The value of ctv_typeidx is the CTF type ID of the data type of the associated
variable. The order in which the CTF types are added can change across
platforms and also as the code evolves, hence changing the CTF type ID. As
there is no direct and portable method of testing that the data type of a CTF
variable is of a specific kind, remove the check on ctv_typeidx.
This also fixes a subset of failures as seen on Darwin.
2021-07-06 Indu Bhagat
gcc/testsuite/ChangeLog:
PR debug/101283
* gcc.dg/debug/ctf/ctf-attr-mode-1.c: Remove the check for ctv_typeidx.
---
gcc/testsuite/gcc.dg/debug/ctf/ctf-attr-mode-1.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-attr-mode-1.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-attr-mode-1.c
index fc3af03..c4801a7 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf-attr-mode-1.c
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-attr-mode-1.c
@@ -1,7 +1,10 @@
/* Test CTF generation works well with ((mode)) attribute.
In this testcase, CTF should report type of bqi to be an enum and
- not an int. */
+ not an int. Also, CTF for typedef of enum should exist. However, there
+ are no direct and portable methods of checking that a CTF type / CTF
+ variable refers to a specific CTF type, so this testcase merely asserts
+ for existence of individual CTF records. */
/* { dg-do compile ) */
/* { dg-options "-O0 -gctf -dA" } */
@@ -16,7 +19,5 @@
/* { dg-final { scan-assembler-times "\[\t \]0x2203\[\t
\]+\[^\n\]*ctt_info" 1 } } */
/* { dg-final { scan-assembler-times "\[\t \]0x2a00\[\t
\]+\[^\n\]*ctt_info" 1 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x3\[\t \]+\[^\n\]*ctv_typeidx"
1} } */
-
typedef enum { B1 = 1, B2 = 2, B3 = 3 } B;
B __attribute__ ((mode (QI))) bqi;
--
1.8.3.1
[PATCH] dwarf2ctf: the unit of sou field location is bits [PR101283]
If the value of the DW_AT_data_member_location attribute is constant, the
associated unit is bytes. This patch amends incorrect behaviour which was being
exercised with -gdwarf-2. This caused some of the failures as noted in PR
debug/101283 (specifically the BTF tests involving btm_offset).
The testcase ctf-struct-array-2.c was erroneously checking for the value of
ctm_offset in number of bytes.
The patch fixes the calculation of the field location value for a struct member
in dwarf2ctf and adjusts the testcase. This patch also fixes some of the
failing tests as noted in PR debug/101283.
2021-07-05 Indu Bhagat
PR debug/101283 - Several tests fail on Darwin with -gctf/gbtf
gcc/ChangeLog:
PR debug/101283
* dwarf2ctf.c (ctf_get_AT_data_member_location): Multiply by 8 to get
number of bits.
gcc/testsuite/ChangeLog:
PR debug/101283
* gcc.dg/debug/ctf/ctf-struct-array-2.c: Adjust the value in the
testcase.
---
gcc/dwarf2ctf.c | 4 ++--
gcc/testsuite/gcc.dg/debug/ctf/ctf-struct-array-2.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/dwarf2ctf.c b/gcc/dwarf2ctf.c
index 08e1252..5e8a725 100644
--- a/gcc/dwarf2ctf.c
+++ b/gcc/dwarf2ctf.c
@@ -100,13 +100,13 @@ ctf_get_AT_data_member_location (dw_die_ref die)
gcc_assert (!descr->dw_loc_oprnd2.v.val_unsigned);
gcc_assert (descr->dw_loc_oprnd2.val_class
== dw_val_class_unsigned_const);
- field_location = descr->dw_loc_oprnd1.v.val_unsigned;
+ field_location = descr->dw_loc_oprnd1.v.val_unsigned * 8;
}
else
{
attr = get_AT (die, DW_AT_data_member_location);
if (attr && AT_class (attr) == dw_val_class_const)
- field_location = AT_int (attr);
+ field_location = AT_int (attr) * 8;
else
field_location = (get_AT_unsigned (die,
DW_AT_data_member_location)
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-struct-array-2.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-struct-array-2.c
index 9e698fd..37094b5 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf-struct-array-2.c
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-struct-array-2.c
@@ -10,6 +10,6 @@
/* { dg-final { scan-assembler-times "0x1200\[\t \]+\[^\n\]*ctt_info" 1 }
} */
/* { dg-final { scan-assembler-times "\[\t \]0x4\[\t \]+\[^\n\]*cta_nelems" 1
} } */
/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*ctm_offset" 1 }
} */
-/* { dg-final { scan-assembler-times "\[\t \]0x4\[\t \]+\[^\n\]*ctm_offset" 1
} } */
+/* { dg-final { scan-assembler-times "\[\t \]0x20\[\t \]+\[^\n\]*ctm_offset" 1
} } */
static struct ranges {int from, to;} lim_regs[] = {{ 16, 7}, { 16, 6}, { 20,
7},{ 20, 6}};
--
1.8.3.1
[COMMITTED] CTF, BTF testsuite: Use -gdwarf-4 for restrict type qualifier [PR101283]
[Committed as obvious.]
DWARF DIEs do not contain DW_TAG_restrict_type when DWARF version is 2. CTF/BTF
generation feeds off DWARF DIEs, and as such, CTF records of kind
CTF_K_RESTRICT cease to be generated when DWARF version is 2.
This patch fixes the failure of these testcases on Darwin by using an explicit
-gdwarf-4 in the dg-options. This keeps the CTF record generation for restrict
type qualifier tested.
PR debug/101283 - Several tests fail on Darwin with -gctf/gbtf
2021-07-05 Indu Bhagat
gcc/testsuite/ChangeLog:
PR debug/101283
* gcc.dg/debug/btf/btf-cvr-quals-1.c: Use -gdwarf-4 on Darwin targets.
* gcc.dg/debug/ctf/ctf-cvr-quals-1.c: Likewise.
---
gcc/testsuite/gcc.dg/debug/btf/btf-cvr-quals-1.c | 1 +
gcc/testsuite/gcc.dg/debug/ctf/ctf-cvr-quals-1.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-cvr-quals-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-cvr-quals-1.c
index 79e9f52..33e2f64 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-cvr-quals-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-cvr-quals-1.c
@@ -23,6 +23,7 @@
/* { dg-do compile } */
/* { dg-options "-O0 -gbtf -dA" } */
+/* { dg-options "-O0 -gbtf -gdwarf-4 -dA" { target { *-*-darwin* } } } */
/* { dg-final { scan-assembler-times "ascii \"int.0\"\[\t
\]+\[^\n\]*btf_string" 1 } } */
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-cvr-quals-1.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-cvr-quals-1.c
index 9368d47..0137e9d 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf-cvr-quals-1.c
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-cvr-quals-1.c
@@ -31,6 +31,7 @@
/* { dg-do compile ) */
/* { dg-options "-O0 -gctf -dA" } */
+/* { dg-options "-O0 -gctf -gdwarf-4 -dA" { target { *-*-darwin* } } } */
/* { dg-final { scan-assembler-times "ascii \"int.0\"\[\t
\]+\[^\n\]*ctf_string" 1 } } */
/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*ctt_name" 7 } }
*/
--
1.8.3.1
[COMMITTED] testsuite: Add missing dg-add-options to CTF testcase ctf-skip-types-4.c
[Noticed this failure on powerpc64. Committed as obvious.]
testsuite: Add missing dg-add-options to CTF testcase ctf-skip-types-4.c
The test already has the appropriate dg-require-effective-target, but requires
the dg-add-options to use the flags needed, if any. This patch fixes the
failure of this testcase on powerpc64.
2021-06-30 Indu Bhagat
gcc/testsuite/
* gcc.dg/debug/ctf/ctf-skip-types-4.c: Add dg-add-options float64 and
float64x.
---
gcc/testsuite/gcc.dg/debug/ctf/ctf-skip-types-4.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/debug/ctf/ctf-skip-types-4.c
b/gcc/testsuite/gcc.dg/debug/ctf/ctf-skip-types-4.c
index f4374e6..7033121 100644
--- a/gcc/testsuite/gcc.dg/debug/ctf/ctf-skip-types-4.c
+++ b/gcc/testsuite/gcc.dg/debug/ctf/ctf-skip-types-4.c
@@ -14,6 +14,8 @@
/* { dg-require-effective-target float64 } */
/* { dg-require-effective-target float64x } */
+/* { dg-add-options float64 } */
+/* { dg-add-options float64x } */
_Float64 f64;
_Float64x f64x;
--
1.8.3.1
[PATCH] Fix PR testsuite/101269
PR testsuite/101269 - new test case gcc.dg/debug/btf/btf-datasec-1.c
fails with its introduction in r12-1852
BTF datasec records for .rodata/.data are expected for now for all targets.
For powerpc based targets, use -msdata=none when ilp32 is enabled.
2021-06-30 Indu Bhagat
gcc/testsuite/ChangeLog:
PR testsuite/101269
* gcc.dg/debug/btf/btf-datasec-1.c: Force -msdata=none with ilp32 for
powerpc based targets.
---
gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index 88ae4c4..f809d93 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -11,6 +11,7 @@
/* { dg-do compile ) */
/* { dg-options "-O0 -gbtf -dA" } */
+/* { dg-options "-O0 -gbtf -dA -msdata=none" { target { { powerpc*-*-* } &&
ilp32 } } } */
/* Check for two DATASEC entries with vlen 3, and one with vlen 1. */
/* { dg-final { scan-assembler-times "0xf03\[\t \]+\[^\n\]*btt_info" 2 } }
*/
--
1.8.3.1
Re: [[PATCH V9] 0/7] Support for the CTF and BTF debug formats
On 6/21/21 7:01 AM, Richard Biener via Gcc-patches wrote: Command line options for debug formats == This implementation adds the following command-line options to select the emission of CTF and BTF: -gctf[123] -gbtf These options mimic the -g[123...] options for DWARF. This involved adding new entries for debug_info_type: CTF_DEBUG- Write CTF debug info. BTF_DEBUG- Write BTF debug info. CTF_AND_DWARF2_DEBUG - Write both CTF and DWARF info. That's probably obsolete info now? Yes, that's correct. Since GCC now supports bitmasks in the write_symbols, defining entries for combination of debug formats like CTF_AND_DWARF2_DEBUG is not necessary. Thanks for pointing it out. Indu
[PATCH,committed] MAINTAINERS: Add myself for write after approval
ChangeLog: 2021-05-31 Indu Bhagat * MAINTAINERS (Write After Approval): Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index fbaa183..d80ed8f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -324,6 +324,7 @@ Andrew Benson Daniel Berlin Pat Bernardi Jan Beulich +Indu Bhagat David Billinghurst Tomas Bily Laurynas Biveinis -- 1.8.3.1
[PATCH] PR testsuite/100749 - gcc.dg/pch/valid-1.c fails after r12-949
Hi,
This patch fixes the failing pch testcases as observed in PR testsuite/100749.
Although the PR mentions powerpc64, the issue exists on other arches but
appears to be latent.
The issue causing the failure was that the underlying char[] df_set_names is a
static var. Multiple calls to 'debug_set_names' with different write_symbols
like the in c-family/c-pch.c must entail the use of xstrdup or such to retain a
reliable copy of the debug format str containing the names.
Bootstrapped, regression tested on x86_64, powepc64 (make check-gcc).
Thanks,
Indu
PR testsuite/100749 - gcc.dg/pch/valid-1.c fails after r12-949
Fix failing pch testcases. Use xstrdup to retain a reliable copy of the debug
format str containing the names (df_set_names is a static string var).
2021-05-28 Indu Bhagat
gcc/c-family/ChangeLog:
* c-pch.c (c_common_valid_pch): Use xstrdup for debug format set names.
---
gcc/c-family/c-pch.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index 8f0f760..5da6042 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -255,10 +255,13 @@ c_common_valid_pch (cpp_reader *pfile, const char *name,
int fd)
if (v.pch_write_symbols != write_symbols
&& write_symbols != NO_DEBUG)
{
+ char *created_str = xstrdup (debug_set_names (v.pch_write_symbols));
+ char *used_str = xstrdup (debug_set_names (write_symbols));
cpp_warning (pfile, CPP_W_INVALID_PCH,
"%s: created with '%s' debug info, but used with '%s'", name,
- debug_set_names (v.pch_write_symbols),
- debug_set_names (write_symbols));
+ created_str, used_str);
+ free (created_str);
+ free (used_str);
return 2;
}
--
1.8.3.1
Re: [PATCH,V3 2/2] dwarf: new dwarf_debuginfo_p predicate
On 5/20/21 2:40 AM, Richard Biener wrote:
On Thu, May 13, 2021 at 12:52 AM Indu Bhagat via Gcc-patches
wrote:
[Changes from V2]
- Tested build (make all-gcc) of cross compiler for target triplets
containing c6x/mips/powerpc and darwin/cygwin.
[End of changes from V2]
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
OK.
Thanks,
Richard.
Committed.
Thanks,
Indu
gcc/c-family/ChangeLog:
* c-lex.c (init_c_lex): Use dwarf_debuginfo_p.
gcc/ChangeLog:
* config/c6x/c6x.c (c6x_output_file_unwind): Use dwarf_debuginfo_p.
* config/darwin.c (darwin_override_options): Likewise.
* config/i386/cygming.h (DBX_REGISTER_NUMBER): Likewise.
* config/i386/darwin.h (DBX_REGISTER_NUMBER): Likewise.
(DWARF2_FRAME_REG_OUT): Likewise.
* config/mips/mips.c (mips_output_filename): Likewise.
* config/rs6000/rs6000.c (rs6000_xcoff_declare_function_name):
Likewise.
(rs6000_dbx_register_number): Likewise.
* dbxout.c: Include flags.h.
* dwarf2cfi.c (cfi_label_required_p): Likewise.
(dwarf2out_do_frame): Likewise.
* except.c: Include flags.h.
* final.c (dwarf2_debug_info_emitted_p): Likewise.
(final_scan_insn_1): Likewise.
* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* targhooks.c (default_debug_unwind_info): Use dwarf_debuginfo_p.
* toplev.c (process_options): Likewise.
---
gcc/c-family/c-lex.c | 4 ++--
gcc/config/c6x/c6x.c | 4 ++--
gcc/config/darwin.c| 3 ++-
gcc/config/i386/cygming.h | 2 +-
gcc/config/i386/darwin.h | 4 ++--
gcc/config/mips/mips.c | 3 ++-
gcc/config/rs6000/rs6000.c | 4 ++--
gcc/dbxout.c | 1 +
gcc/dwarf2cfi.c| 9 -
gcc/except.c | 1 +
gcc/final.c| 15 ++-
gcc/flags.h| 4
gcc/opts.c | 8
gcc/targhooks.c| 2 +-
gcc/toplev.c | 6 ++
15 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 1c66ecd..c44e7a1 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3. If not see
#include "stor-layout.h"
#include "c-pragma.h"
#include "debug.h"
+#include "flags.h"
#include "file-prefix-map.h" /* remap_macro_filename() */
#include "langhooks.h"
#include "attribs.h"
@@ -87,8 +88,7 @@ init_c_lex (void)
/* Set the debug callbacks if we can use them. */
if ((debug_info_level == DINFO_LEVEL_VERBOSE
- && (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG))
+ && dwarf_debuginfo_p ())
|| flag_dump_go_spec != NULL)
{
cb->define = cb_define;
diff --git a/gcc/config/c6x/c6x.c b/gcc/config/c6x/c6x.c
index f9ad1e5..e2011f0 100644
--- a/gcc/config/c6x/c6x.c
+++ b/gcc/config/c6x/c6x.c
@@ -59,6 +59,7 @@
#include "regrename.h"
#include "dumpfile.h"
#include "builtins.h"
+#include "flags.h"
/* This file should be included last. */
#include "target-def.h"
@@ -439,8 +440,7 @@ c6x_output_file_unwind (FILE * f)
{
if (flag_unwind_tables || flag_exceptions)
{
- if (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG)
+ if (dwarf_debuginfo_p ())
asm_fprintf (f, "\t.cfi_sections .debug_frame, .c6xabi.exidx\n");
else
asm_fprintf (f, "\t.cfi_sections .c6xabi.exidx\n");
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index 5d17391..026c1fb 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3. If not see
#include "lto-section-names.h"
#include "intl.h"
#include "optabs.h"
+#include "flags.h"
/* Fix and Continue.
@@ -3348,7 +3349,7 @@ darwin_override_options (void)
&& generating_for_darwin_version >= 9
&& (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE)
: (debug_info_level >= DINFO_LEVEL_NORMAL))
- && write_symbols == DWARF2_DEBUG)
+ && dwarf_debuginfo_p ())
flag_var_tracking_uninit = flag_var_tracking;
/* Final check on PCI options; for Darwin these are not dependent on the PIE
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index cfbca34..ac458cd 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -82,7 +82,7 @@ along with GCC; see the file COPYING3. If not see
Re: [PATCH,V3 1/2] opts: change write_symbols to support bitmasks
On 5/20/21 2:40 AM, Richard Biener wrote:
On Thu, May 13, 2021 at 12:53 AM Indu Bhagat via Gcc-patches
wrote:
[No changes from V2]
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
OK.
Thanks,
Richard.
Committed.
Thanks,
Indu
gcc/c-family/ChangeLog:
* c-opts.c (c_common_post_options): Adjust access to debug_type_names.
* c-pch.c (struct c_pch_validity): Use type uint32_t.
(pch_init): Renamed member.
(c_common_valid_pch): Adjust access to debug_type_names.
gcc/ChangeLog:
* common.opt: Change type to support bitmasks.
* flag-types.h (enum debug_info_type): Rename enumerator constants.
(NO_DEBUG): New bitmask.
(DBX_DEBUG): Likewise.
(DWARF2_DEBUG): Likewise.
(XCOFF_DEBUG): Likewise.
(VMS_DEBUG): Likewise.
(VMS_AND_DWARF2_DEBUG): Likewise.
* flags.h (debug_set_to_format): New function declaration.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
* opts.c (debug_type_masks): Array of bitmasks for debug formats.
(debug_set_to_format): New function definition.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
(set_debug_level): Update access to debug_type_names.
* toplev.c: Likewise.
gcc/objc/ChangeLog:
* objc-act.c (synth_module_prologue): Use uint32_t instead of enum
debug_info_type.
gcc/testsuite/ChangeLog:
* gcc.dg/pch/valid-1.c: Adjust diagnostic message in testcase.
* lib/dg-pch.exp: Adjust diagnostic message.
---
gcc/c-family/c-opts.c | 7 ++-
gcc/c-family/c-pch.c | 12 ++--
gcc/common.opt | 2 +-
gcc/flag-types.h | 29 +++---
gcc/flags.h| 17 +-
gcc/objc/objc-act.c| 2 +-
gcc/opts.c | 109 +
gcc/testsuite/gcc.dg/pch/valid-1.c | 2 +-
gcc/testsuite/lib/dg-pch.exp | 4 +-
gcc/toplev.c | 9 ++-
10 files changed, 157 insertions(+), 36 deletions(-)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 89e05a4..60b5802 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1112,9 +1112,10 @@ c_common_post_options (const char **pfilename)
/* Only -g0 and -gdwarf* are supported with PCH, for other
debug formats we warn here and refuse to load any PCH files. */
if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
- warning (OPT_Wdeprecated,
-"the %qs debug format cannot be used with "
-"pre-compiled headers", debug_type_names[write_symbols]);
+ warning (OPT_Wdeprecated,
+ "the %qs debug info cannot be used with "
+ "pre-compiled headers",
+ debug_set_names (write_symbols & ~DWARF2_DEBUG));
}
else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
c_common_no_more_pch ();
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index fd94c37..8f0f760 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -52,7 +52,7 @@ enum {
struct c_pch_validity
{
- unsigned char debug_info_type;
+ uint32_t pch_write_symbols;
signed char match[MATCH_SIZE];
void (*pch_init) (void);
size_t target_data_length;
@@ -108,7 +108,7 @@ pch_init (void)
pch_outfile = f;
memset (&v, '\0', sizeof (v));
- v.debug_info_type = write_symbols;
+ v.pch_write_symbols = write_symbols;
{
size_t i;
for (i = 0; i < MATCH_SIZE; i++)
@@ -252,13 +252,13 @@ c_common_valid_pch (cpp_reader *pfile, const char *name,
int fd)
/* The allowable debug info combinations are that either the PCH file
was built with the same as is being used now, or the PCH file was
built for some kind of debug info but now none is in use. */
- if (v.debug_info_type != write_symbols
+ if (v.pch_write_symbols != write_symbols
&& write_symbols != NO_DEBUG)
{
cpp_warning (pfile, CPP_W_INVALID_PCH,
- "%s: created with -g%s, but used with -g%s", name,
- debug_type_names[v.debug_info_type],
- debug_type_names[write_symbols]);
+ "%s: created with '%s' debug info, but used with '%s'", name,
+ debug_set_names (v.pch_write_symbols),
+ debug_set_names (write_symbols));
return 2;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index a75b44e..ffb968d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -109,7 +109,7 @@ bool exit_after_options
; flag-types.h for the defini
[PATCH,V3 1/2] opts: change write_symbols to support bitmasks
[No changes from V2]
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
gcc/c-family/ChangeLog:
* c-opts.c (c_common_post_options): Adjust access to debug_type_names.
* c-pch.c (struct c_pch_validity): Use type uint32_t.
(pch_init): Renamed member.
(c_common_valid_pch): Adjust access to debug_type_names.
gcc/ChangeLog:
* common.opt: Change type to support bitmasks.
* flag-types.h (enum debug_info_type): Rename enumerator constants.
(NO_DEBUG): New bitmask.
(DBX_DEBUG): Likewise.
(DWARF2_DEBUG): Likewise.
(XCOFF_DEBUG): Likewise.
(VMS_DEBUG): Likewise.
(VMS_AND_DWARF2_DEBUG): Likewise.
* flags.h (debug_set_to_format): New function declaration.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
* opts.c (debug_type_masks): Array of bitmasks for debug formats.
(debug_set_to_format): New function definition.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
(set_debug_level): Update access to debug_type_names.
* toplev.c: Likewise.
gcc/objc/ChangeLog:
* objc-act.c (synth_module_prologue): Use uint32_t instead of enum
debug_info_type.
gcc/testsuite/ChangeLog:
* gcc.dg/pch/valid-1.c: Adjust diagnostic message in testcase.
* lib/dg-pch.exp: Adjust diagnostic message.
---
gcc/c-family/c-opts.c | 7 ++-
gcc/c-family/c-pch.c | 12 ++--
gcc/common.opt | 2 +-
gcc/flag-types.h | 29 +++---
gcc/flags.h| 17 +-
gcc/objc/objc-act.c| 2 +-
gcc/opts.c | 109 +
gcc/testsuite/gcc.dg/pch/valid-1.c | 2 +-
gcc/testsuite/lib/dg-pch.exp | 4 +-
gcc/toplev.c | 9 ++-
10 files changed, 157 insertions(+), 36 deletions(-)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 89e05a4..60b5802 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1112,9 +1112,10 @@ c_common_post_options (const char **pfilename)
/* Only -g0 and -gdwarf* are supported with PCH, for other
debug formats we warn here and refuse to load any PCH files. */
if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
- warning (OPT_Wdeprecated,
-"the %qs debug format cannot be used with "
-"pre-compiled headers", debug_type_names[write_symbols]);
+ warning (OPT_Wdeprecated,
+ "the %qs debug info cannot be used with "
+ "pre-compiled headers",
+ debug_set_names (write_symbols & ~DWARF2_DEBUG));
}
else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
c_common_no_more_pch ();
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index fd94c37..8f0f760 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -52,7 +52,7 @@ enum {
struct c_pch_validity
{
- unsigned char debug_info_type;
+ uint32_t pch_write_symbols;
signed char match[MATCH_SIZE];
void (*pch_init) (void);
size_t target_data_length;
@@ -108,7 +108,7 @@ pch_init (void)
pch_outfile = f;
memset (&v, '\0', sizeof (v));
- v.debug_info_type = write_symbols;
+ v.pch_write_symbols = write_symbols;
{
size_t i;
for (i = 0; i < MATCH_SIZE; i++)
@@ -252,13 +252,13 @@ c_common_valid_pch (cpp_reader *pfile, const char *name,
int fd)
/* The allowable debug info combinations are that either the PCH file
was built with the same as is being used now, or the PCH file was
built for some kind of debug info but now none is in use. */
- if (v.debug_info_type != write_symbols
+ if (v.pch_write_symbols != write_symbols
&& write_symbols != NO_DEBUG)
{
cpp_warning (pfile, CPP_W_INVALID_PCH,
- "%s: created with -g%s, but used with -g%s", name,
- debug_type_names[v.debug_info_type],
- debug_type_names[write_symbols]);
+ "%s: created with '%s' debug info, but used with '%s'", name,
+ debug_set_names (v.pch_write_symbols),
+ debug_set_names (write_symbols));
return 2;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index a75b44e..ffb968d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -109,7 +109,7 @@ bool exit_after_options
; flag-types.h for the definitions of the different possible types of
; debugging information.
Variable
-enum debug_info_type write_symbols = NO_DEBUG
+uint32_t write_symbols = NO_DEBUG
; Level of debugging information we are producing. See flag-types.h
; for the definitions of the different possible levels.
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index a038c8f
[PATCH,V3 2/2] dwarf: new dwarf_debuginfo_p predicate
[Changes from V2]
- Tested build (make all-gcc) of cross compiler for target triplets
containing c6x/mips/powerpc and darwin/cygwin.
[End of changes from V2]
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
gcc/c-family/ChangeLog:
* c-lex.c (init_c_lex): Use dwarf_debuginfo_p.
gcc/ChangeLog:
* config/c6x/c6x.c (c6x_output_file_unwind): Use dwarf_debuginfo_p.
* config/darwin.c (darwin_override_options): Likewise.
* config/i386/cygming.h (DBX_REGISTER_NUMBER): Likewise.
* config/i386/darwin.h (DBX_REGISTER_NUMBER): Likewise.
(DWARF2_FRAME_REG_OUT): Likewise.
* config/mips/mips.c (mips_output_filename): Likewise.
* config/rs6000/rs6000.c (rs6000_xcoff_declare_function_name):
Likewise.
(rs6000_dbx_register_number): Likewise.
* dbxout.c: Include flags.h.
* dwarf2cfi.c (cfi_label_required_p): Likewise.
(dwarf2out_do_frame): Likewise.
* except.c: Include flags.h.
* final.c (dwarf2_debug_info_emitted_p): Likewise.
(final_scan_insn_1): Likewise.
* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* targhooks.c (default_debug_unwind_info): Use dwarf_debuginfo_p.
* toplev.c (process_options): Likewise.
---
gcc/c-family/c-lex.c | 4 ++--
gcc/config/c6x/c6x.c | 4 ++--
gcc/config/darwin.c| 3 ++-
gcc/config/i386/cygming.h | 2 +-
gcc/config/i386/darwin.h | 4 ++--
gcc/config/mips/mips.c | 3 ++-
gcc/config/rs6000/rs6000.c | 4 ++--
gcc/dbxout.c | 1 +
gcc/dwarf2cfi.c| 9 -
gcc/except.c | 1 +
gcc/final.c| 15 ++-
gcc/flags.h| 4
gcc/opts.c | 8
gcc/targhooks.c| 2 +-
gcc/toplev.c | 6 ++
15 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 1c66ecd..c44e7a1 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3. If not see
#include "stor-layout.h"
#include "c-pragma.h"
#include "debug.h"
+#include "flags.h"
#include "file-prefix-map.h" /* remap_macro_filename() */
#include "langhooks.h"
#include "attribs.h"
@@ -87,8 +88,7 @@ init_c_lex (void)
/* Set the debug callbacks if we can use them. */
if ((debug_info_level == DINFO_LEVEL_VERBOSE
- && (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG))
+ && dwarf_debuginfo_p ())
|| flag_dump_go_spec != NULL)
{
cb->define = cb_define;
diff --git a/gcc/config/c6x/c6x.c b/gcc/config/c6x/c6x.c
index f9ad1e5..e2011f0 100644
--- a/gcc/config/c6x/c6x.c
+++ b/gcc/config/c6x/c6x.c
@@ -59,6 +59,7 @@
#include "regrename.h"
#include "dumpfile.h"
#include "builtins.h"
+#include "flags.h"
/* This file should be included last. */
#include "target-def.h"
@@ -439,8 +440,7 @@ c6x_output_file_unwind (FILE * f)
{
if (flag_unwind_tables || flag_exceptions)
{
- if (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG)
+ if (dwarf_debuginfo_p ())
asm_fprintf (f, "\t.cfi_sections .debug_frame, .c6xabi.exidx\n");
else
asm_fprintf (f, "\t.cfi_sections .c6xabi.exidx\n");
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index 5d17391..026c1fb 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3. If not see
#include "lto-section-names.h"
#include "intl.h"
#include "optabs.h"
+#include "flags.h"
/* Fix and Continue.
@@ -3348,7 +3349,7 @@ darwin_override_options (void)
&& generating_for_darwin_version >= 9
&& (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE)
: (debug_info_level >= DINFO_LEVEL_NORMAL))
- && write_symbols == DWARF2_DEBUG)
+ && dwarf_debuginfo_p ())
flag_var_tracking_uninit = flag_var_tracking;
/* Final check on PCI options; for Darwin these are not dependent on the PIE
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index cfbca34..ac458cd 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -82,7 +82,7 @@ along with GCC; see the file COPYING3. If not see
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) \
(TARGET_64BIT ? dbx64_register_map[n]\
- : (write_symbols == DWARF2_DEBUG\
+ : (dwarf_debuginfo_p () \
? svr4_dbx_register_map[n] : dbx_register_map[n]))
/* Map gcc register number to DWARF 2 CFA column number. For 32 bit
diff --git a/gcc/config/i386/darwin.h b/gcc/config/i386/darwin.h
index afa9f1b..5312003 100644
--- a/gcc
[PATCH, V3 0/2] Fix write_symbols for supporting multiple debug formats
[Changes across versions] [What's new in V2] - (Addressed Richard's comments) - For patch 1/2 [opts: change write_symbols to support bitmasks], use debug_set_names more uniformly. Reworded the diagnostics in c-family/c-opts.c and c-family/c-pch.c as there can be multiple debug formats. Updated the testsuite files accordingly. - Included more backend files for patch 2/2 [dwarf: new dwarf_debuginfo_p predicate] - Regression tested on x86_64. [What's new in V3] - (Addressed Richard's comments) - Include flags.h in relevant files. Tested build (make all-gcc) for triplets with c6x/mips/powerpc and darwin/cygwin. [End of changes across versions] Hello, Over the last year, we have discussed and agreed that in order to support multiple debug formats, we keep DWARF as defacto internal format and any new debug format to be supported feeds off DWARF dies. This requirement specification has worked well for addition for CTF/BTF overall. There are some existing issues that need to discussed and fixed in this regard, though. One of these is the definition and handling of write_symbols. The current issue is that write_symbols is defined as enum debug_info_type write_symbols = NO_DEBUG; This means any new combination of debug formats needs to be explicitly enumerated, like CTF_AND_DWARF2_DEBUG, VMS_AND_DWARF2_DEBUG etc. So the issue is, to support say, -gctf -gbtf -g or possibly other combination of debug formats to work together, each one needs to spelled out explicitly; which will make the handling ugly. This patch set updates write_symbols to use bitmasks. Regression tested on x86_64, apart from simple (make all-gcc) builds for select target triplets to cover c6x/mips/powerpc and cygwin/darwin. Thanks, Indu Bhagat (2): opts: change write_symbols to support bitmasks dwarf: new dwarf_debuginfo_p predicate gcc/c-family/c-lex.c | 4 +- gcc/c-family/c-opts.c | 7 ++- gcc/c-family/c-pch.c | 12 ++-- gcc/common.opt | 2 +- gcc/config/c6x/c6x.c | 4 +- gcc/config/darwin.c| 3 +- gcc/config/i386/cygming.h | 2 +- gcc/config/i386/darwin.h | 4 +- gcc/config/mips/mips.c | 3 +- gcc/config/rs6000/rs6000.c | 4 +- gcc/dbxout.c | 1 + gcc/dwarf2cfi.c| 9 ++- gcc/except.c | 1 + gcc/final.c| 15 ++--- gcc/flag-types.h | 29 ++--- gcc/flags.h| 21 ++- gcc/objc/objc-act.c| 2 +- gcc/opts.c | 117 + gcc/targhooks.c| 2 +- gcc/testsuite/gcc.dg/pch/valid-1.c | 2 +- gcc/testsuite/lib/dg-pch.exp | 4 +- gcc/toplev.c | 15 ++--- 22 files changed, 197 insertions(+), 66 deletions(-) -- 1.8.3.1
Re: [PATCH 1/2] opts: change write_symbols to support bitmasks
On 5/12/21 12:31 AM, Richard Biener wrote: Otherwise looks OK. Did you check for write_symbols uses in FEs and targets? Richard. Yes, I have. I must admit I have gone back and forth in my mind on this. My initial thinking was to adjust only those checks where I expect more than 1 write_symbols. Because in most contexts, e.g., (write_symbols == XCOFF_DEBUG) is a stricter check than (write_symbols & XCOFF_DEBUG), in some sense. Anyway, after you raised this point, however, I looked again, and have added some dwarf_debuginfo_p usages in the second patch. Basically, I replaced some write_symbols == DWARF2_DEBUG with dwarf_debuginfo_p () usage. Other than DWARF2_DEBUG, at this time, no other debug format is expected to be written out together with other debug formats. As for other usages of write_symbols - I plan to get rid of the VMS_AND_DWARF2_DEBUG symbol in a subsequent patch (this should deal with most usages in vmsdbgout.c). I will post V2 next. A question though - I have regression tested the V2 patch set on x86_64. Although the sort of changes in the backend files can be OK, I am happy to take any further suggestions for testing this patch set. If you touch backends in non-trivial ways it's at least good to test it still builds in a simple cross configuration which means configuring for one of the supported target triplets and doing make all-gcc (that only builds host objects so you don't need binutils or target headers for this) Richard. Thanks. I tested the patch set for select triplets containing c6x/mips/powerpc and cygwin/darwin. Found and fixed the build issues. Will be posting V3 next. Thanks Indu
[PATCH,V2 2/2] dwarf: new dwarf_debuginfo_p predicate
[Changes from V1]
- included checks in
- config/darwin.c
- config/i386/cygming.h
- config/i386/darwin.h
- config/mips/mips.c
- config/rs6000/rs6000.c
[End of changes from V1]
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
gcc/c-family/ChangeLog:
* c-lex.c (init_c_lex): Use dwarf_debuginfo_p.
gcc/ChangeLog:
* config/c6x/c6x.c (c6x_output_file_unwind): Use dwarf_debuginfo_p.
* config/darwin.c (darwin_override_options): Likewise.
* config/i386/cygming.h (DBX_REGISTER_NUMBER): Likewise.
* config/i386/darwin.h (DBX_REGISTER_NUMBER): Likewise.
(DWARF2_FRAME_REG_OUT): Likewise.
* config/mips/mips.c (mips_output_filename): Likewise.
* config/rs6000/rs6000.c (rs6000_xcoff_declare_function_name):
Likewise.
(rs6000_dbx_register_number): Likewise.
* dwarf2cfi.c (cfi_label_required_p): Likewise.
(dwarf2out_do_frame): Likewise.
* final.c (dwarf2_debug_info_emitted_p): Likewise.
(final_scan_insn_1): Likewise.
* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* targhooks.c (default_debug_unwind_info): Use dwarf_debuginfo_p.
* toplev.c (process_options): Likewise.
---
gcc/c-family/c-lex.c | 4 ++--
gcc/config/c6x/c6x.c | 3 +--
gcc/config/darwin.c| 2 +-
gcc/config/i386/cygming.h | 2 +-
gcc/config/i386/darwin.h | 4 ++--
gcc/config/mips/mips.c | 2 +-
gcc/config/rs6000/rs6000.c | 4 ++--
gcc/dwarf2cfi.c| 9 -
gcc/final.c| 15 ++-
gcc/flags.h| 4
gcc/opts.c | 8
gcc/targhooks.c| 2 +-
gcc/toplev.c | 6 ++
13 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 6374b72..5174b22 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3. If not see
#include "stor-layout.h"
#include "c-pragma.h"
#include "debug.h"
+#include "flags.h"
#include "file-prefix-map.h" /* remap_macro_filename() */
#include "langhooks.h"
#include "attribs.h"
@@ -87,8 +88,7 @@ init_c_lex (void)
/* Set the debug callbacks if we can use them. */
if ((debug_info_level == DINFO_LEVEL_VERBOSE
- && (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG))
+ && dwarf_debuginfo_p ())
|| flag_dump_go_spec != NULL)
{
cb->define = cb_define;
diff --git a/gcc/config/c6x/c6x.c b/gcc/config/c6x/c6x.c
index f9ad1e5..a10e2f8 100644
--- a/gcc/config/c6x/c6x.c
+++ b/gcc/config/c6x/c6x.c
@@ -439,8 +439,7 @@ c6x_output_file_unwind (FILE * f)
{
if (flag_unwind_tables || flag_exceptions)
{
- if (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG)
+ if (dwarf_debuginfo_p ())
asm_fprintf (f, "\t.cfi_sections .debug_frame, .c6xabi.exidx\n");
else
asm_fprintf (f, "\t.cfi_sections .c6xabi.exidx\n");
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index 5d17391..b937914 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -3348,7 +3348,7 @@ darwin_override_options (void)
&& generating_for_darwin_version >= 9
&& (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE)
: (debug_info_level >= DINFO_LEVEL_NORMAL))
- && write_symbols == DWARF2_DEBUG)
+ && dwarf_debuginfo_p ())
flag_var_tracking_uninit = flag_var_tracking;
/* Final check on PCI options; for Darwin these are not dependent on the PIE
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index cfbca34..ac458cd 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -82,7 +82,7 @@ along with GCC; see the file COPYING3. If not see
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) \
(TARGET_64BIT ? dbx64_register_map[n]\
- : (write_symbols == DWARF2_DEBUG\
+ : (dwarf_debuginfo_p () \
? svr4_dbx_register_map[n] : dbx_register_map[n]))
/* Map gcc register number to DWARF 2 CFA column number. For 32 bit
diff --git a/gcc/config/i386/darwin.h b/gcc/config/i386/darwin.h
index afa9f1b..5312003 100644
--- a/gcc/config/i386/darwin.h
+++ b/gcc/config/i386/darwin.h
@@ -275,13 +275,13 @@ along with GCC; see the file COPYING3. If not see
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) \
(TARGET_64BIT ? dbx64_register_map[n]\
- : write_symbols == DWARF2_DEBUG ? svr4_dbx_register_map[n] \
+ : dwarf_debuginfo_p () ? svr4_dbx_register_map[n] \
: dbx_register_map[n])
/* Unfortunatel
[PATCH,V2 1/2] opts: change write_symbols to support bitmasks
[Changes from V1]
- Use debug_set_names API and remove asserts around the diagnostics
- Reword diagnostic and adjust testsuite
[End of changes from V1]
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
gcc/c-family/ChangeLog:
* c-opts.c (c_common_post_options): Adjust access to debug_type_names.
* c-pch.c (struct c_pch_validity): Use type uint32_t.
(pch_init): Renamed member.
(c_common_valid_pch): Adjust access to debug_type_names.
gcc/ChangeLog:
* common.opt: Change type to support bitmasks.
* flag-types.h (enum debug_info_type): Rename enumerator constants.
(NO_DEBUG): New bitmask.
(DBX_DEBUG): Likewise.
(DWARF2_DEBUG): Likewise.
(XCOFF_DEBUG): Likewise.
(VMS_DEBUG): Likewise.
(VMS_AND_DWARF2_DEBUG): Likewise.
* flags.h (debug_set_to_format): New function declaration.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
* opts.c (debug_type_masks): Array of bitmasks for debug formats.
(debug_set_to_format): New function definition.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
(set_debug_level): Update access to debug_type_names.
* toplev.c: Likewise.
gcc/objc/ChangeLog:
* objc-act.c (synth_module_prologue): Use uint32_t instead of enum
debug_info_type.
gcc/testsuite/ChangeLog:
* gcc.dg/pch/valid-1.c: Adjust diagnostic message in testcase.
* lib/dg-pch.exp: Adjust diagnostic message.
---
gcc/c-family/c-opts.c | 7 ++-
gcc/c-family/c-pch.c | 12 ++--
gcc/common.opt | 2 +-
gcc/flag-types.h | 29 +++---
gcc/flags.h| 17 +-
gcc/objc/objc-act.c| 2 +-
gcc/opts.c | 109 +
gcc/testsuite/gcc.dg/pch/valid-1.c | 2 +-
gcc/testsuite/lib/dg-pch.exp | 4 +-
gcc/toplev.c | 9 ++-
10 files changed, 157 insertions(+), 36 deletions(-)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 89e05a4..60b5802 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1112,9 +1112,10 @@ c_common_post_options (const char **pfilename)
/* Only -g0 and -gdwarf* are supported with PCH, for other
debug formats we warn here and refuse to load any PCH files. */
if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
- warning (OPT_Wdeprecated,
-"the %qs debug format cannot be used with "
-"pre-compiled headers", debug_type_names[write_symbols]);
+ warning (OPT_Wdeprecated,
+ "the %qs debug info cannot be used with "
+ "pre-compiled headers",
+ debug_set_names (write_symbols & ~DWARF2_DEBUG));
}
else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
c_common_no_more_pch ();
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index fd94c37..8f0f760 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -52,7 +52,7 @@ enum {
struct c_pch_validity
{
- unsigned char debug_info_type;
+ uint32_t pch_write_symbols;
signed char match[MATCH_SIZE];
void (*pch_init) (void);
size_t target_data_length;
@@ -108,7 +108,7 @@ pch_init (void)
pch_outfile = f;
memset (&v, '\0', sizeof (v));
- v.debug_info_type = write_symbols;
+ v.pch_write_symbols = write_symbols;
{
size_t i;
for (i = 0; i < MATCH_SIZE; i++)
@@ -252,13 +252,13 @@ c_common_valid_pch (cpp_reader *pfile, const char *name,
int fd)
/* The allowable debug info combinations are that either the PCH file
was built with the same as is being used now, or the PCH file was
built for some kind of debug info but now none is in use. */
- if (v.debug_info_type != write_symbols
+ if (v.pch_write_symbols != write_symbols
&& write_symbols != NO_DEBUG)
{
cpp_warning (pfile, CPP_W_INVALID_PCH,
- "%s: created with -g%s, but used with -g%s", name,
- debug_type_names[v.debug_info_type],
- debug_type_names[write_symbols]);
+ "%s: created with '%s' debug info, but used with '%s'", name,
+ debug_set_names (v.pch_write_symbols),
+ debug_set_names (write_symbols));
return 2;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index a75b44e..ffb968d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -109,7 +109,7 @@ bool exit_after_options
; flag-types.h for the definitions of the different possible types of
; debugging information.
Variable
-enum debug_info_type write_symbols = NO_DEBUG
+uint32_t write_symbols = NO_DEBUG
; Level of debugging information we are producing. S
[PATCH, V2 0/2] Fix write_symbols for supporting multiple debug formats
[Changes from V1] - (Addressed Richard's comments) - For patch 1/2 [opts: change write_symbols to support bitmasks], use debug_set_names more uniformly. Reworded the diagnostics in c-family/c-opts.c and c-family/c-pch.c as there can be multiple debug formats. Updated the testsuite files accordingly. - Included more backend files for patch 2/2 [dwarf: new dwarf_debuginfo_p predicate] - Regression tested on x86_64. Open for any suggestions on further testing. [End of changes from V1] Hello, Over the last year, we have discussed and agreed that in order to support multiple debug formats, we keep DWARF as defacto internal format and any new debug format to be supported feeds off DWARF dies. This requirement specification has worked well for addition for CTF/BTF overall. There are some existing issues that need to discussed and fixed in this regard, though. One of these is the definition and handling of write_symbols. The current issue is that write_symbols is defined as enum debug_info_type write_symbols = NO_DEBUG; This means any new combination of debug formats needs to be explicitly enumerated, like CTF_AND_DWARF2_DEBUG, VMS_AND_DWARF2_DEBUG etc. So the issue is, to support say, -gctf -gbtf -g or possibly other combination of debug formats to work together, each one needs to spelled out explicitly; which will make the handling ugly. This patch set updates write_symbols to use bitmasks. Thanks, Indu Bhagat (2): opts: change write_symbols to support bitmasks dwarf: new dwarf_debuginfo_p predicate gcc/c-family/c-lex.c | 4 +- gcc/c-family/c-opts.c | 7 ++- gcc/c-family/c-pch.c | 12 ++-- gcc/common.opt | 2 +- gcc/config/c6x/c6x.c | 3 +- gcc/config/darwin.c| 2 +- gcc/config/i386/cygming.h | 2 +- gcc/config/i386/darwin.h | 4 +- gcc/config/mips/mips.c | 2 +- gcc/config/rs6000/rs6000.c | 4 +- gcc/dwarf2cfi.c| 9 ++- gcc/final.c| 15 ++--- gcc/flag-types.h | 29 ++--- gcc/flags.h| 21 ++- gcc/objc/objc-act.c| 2 +- gcc/opts.c | 117 + gcc/targhooks.c| 2 +- gcc/testsuite/gcc.dg/pch/valid-1.c | 2 +- gcc/testsuite/lib/dg-pch.exp | 4 +- gcc/toplev.c | 15 ++--- 20 files changed, 192 insertions(+), 66 deletions(-) -- 1.8.3.1
Re: [PATCH 1/2] opts: change write_symbols to support bitmasks
On 5/10/21 6:11 AM, Richard Biener wrote:
On Thu, May 6, 2021 at 2:31 AM Indu Bhagat via Gcc-patches
wrote:
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
debug_set_names with its static buffer seems unused? You wire quite some
APIs with gcc_assert on having a single bit set - that doesn't look forward
looking.
I suppose the BTF followups will "fix" this, but see comments below.
Thanks for your feedback.
Yes, I intended to fix them when I added the CTF/BTF as then I would
have a way to debug/test it more meaningfully. Because of this, the
debug_set_names and the associated static buffer were unused in V1 indeed.
For V2, taking your inputs, I have now fixed the uses in c-opts.c and
c-pch.c at least.
gcc/c-family/ChangeLog:
* c-opts.c (c_common_post_options): Adjust access to debug_type_names.
* c-pch.c (struct c_pch_validity): Use type uint32_t.
(pch_init): Renamed member.
(c_common_valid_pch): Adjust access to debug_type_names.
gcc/ChangeLog:
* common.opt: Change type to support bitmasks.
* flag-types.h (enum debug_info_type): Rename enumerator constants.
(NO_DEBUG): New bitmask.
(DBX_DEBUG): Likewise.
(DWARF2_DEBUG): Likewise.
(XCOFF_DEBUG): Likewise.
(VMS_DEBUG): Likewise.
(VMS_AND_DWARF2_DEBUG): Likewise.
* flags.h (debug_set_to_format): New function declaration.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
* opts.c (debug_type_masks): Array of bitmasks for debug formats.
(debug_set_to_format): New function definition.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
(set_debug_level): Update access to debug_type_names.
* toplev.c: Likewise.
gcc/objc/ChangeLog:
* objc-act.c (synth_module_prologue): Use uint32_t instead of enum
debug_info_type.
---
gcc/c-family/c-opts.c | 10 +++--
gcc/c-family/c-pch.c | 12 +++---
gcc/common.opt| 2 +-
gcc/flag-types.h | 29 ++
gcc/flags.h | 17 +++-
gcc/objc/objc-act.c | 2 +-
gcc/opts.c| 109 +-
gcc/toplev.c | 9 +++--
8 files changed, 158 insertions(+), 32 deletions(-)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 89e05a4..e463240 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1112,9 +1112,13 @@ c_common_post_options (const char **pfilename)
/* Only -g0 and -gdwarf* are supported with PCH, for other
debug formats we warn here and refuse to load any PCH files. */
if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
- warning (OPT_Wdeprecated,
-"the %qs debug format cannot be used with "
-"pre-compiled headers", debug_type_names[write_symbols]);
+ {
+ gcc_assert (debug_set_count (write_symbols) <= 1);
Why this assert? Iff then simply include the count check in the
condition of the warning.
+ warning (OPT_Wdeprecated,
+ "the %qs debug format cannot be used with "
+ "pre-compiled headers",
+ debug_type_names[debug_set_to_format (write_symbols)]);
Maybe simply emit another diagnostic if debug_set_count > 1.
OK. I have removed the asserts. The code now uses debug_set_names
uniformly. I have changed the diagnostic message, as there can be
multiple debug formats for PCH at some point. So,
from "the 'XXX' debug format cannot be used with pre-compiled headers"
to "the 'XXX YYY' debug info cannot be used with pre-compiled headers"
if multiple debug formats were enabled.
+ }
}
else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
c_common_no_more_pch ();
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index fd94c37..6804388 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -52,7 +52,7 @@ enum {
struct c_pch_validity
{
- unsigned char debug_info_type;
+ uint32_t pch_write_symbols;
signed char match[MATCH_SIZE];
void (*pch_init) (void);
size_t target_data_length;
@@ -108,7 +108,7 @@ pch_init (void)
pch_outfile = f;
memset (&v, '\0', sizeof (v));
- v.debug_info_type = write_symbols;
+ v.pch_write_symbols = write_symbols;
{
size_t i;
for (i = 0; i < MATCH_SIZE; i++)
@@ -252,13 +252,15 @@ c_common_valid_pch (cpp_reader *pfile, const char *name,
int fd)
/* The allowable debug info combinations are that either the PCH file
was built with the same as is being used now, or the PCH file was
built for som
Re: [PATCH V7 4/7] CTF/BTF debug formats
On 4/29/21 11:17 PM, Richard Biener wrote:
On Thu, 29 Apr 2021, Indu Bhagat wrote:
Hello,
On 4/29/21 5:10 AM, Richard Biener wrote:
On Thu, 29 Apr 2021, Jose E. Marchesi wrote:
This commit introduces support for generating CTF debugging
information and BTF debugging information from GCC.
Comments inline.
Thanks for your reviews.
My responses and questions inline at respective points.
Indu
+#ifndef GCC_CTFC_H
+#define GCC_CTFC_H 1
+
+#include "config.h"
+#include "system.h"
+#include "tree.h"
+#include "fold-const.h"
+#include "dwarf2ctf.h"
+#include "ctf.h"
+#include "btf.h"
+
+/* Invalid CTF type ID definition. */
+
+#define CTF_NULL_TYPEID 0
+
+/* Value to start generating the CTF type ID from. */
+
+#define CTF_INIT_TYPEID 1
+
+/* CTF type ID. */
+
+typedef unsigned long ctf_id_t;
+
+/* CTF string table element (list node). */
+
+typedef struct GTY ((chain_next ("%h.cts_next"))) ctf_string
I know that DWARF takes the lead here but do all these have to
live in GC memory? The reason the DWARF bits do is that they
point to 'tree' and that trees point to DIEs.
Not entirely sure what you mean here ? Do you mean to not tag it as GC root
and avoid traversal for GC marking the individual strings ?
Basically think of what part of the CTF data structures can live on the
heap (since you should know lifetime pretty well).
OK. I have added code to release the memory for CTF strings for now when
the CTF container is finalized. This change will be included in the next
patch series.
+{
+ dw_die_ref type_die = get_AT_ref (die, DW_AT_type);
+ return (type_die ? type_die : ctf_void_die);
+}
+
+/* Some data member DIEs have location specified as a DWARF expression
+ (specifically in DWARF2). Luckily, the expression is a simple
+ DW_OP_plus_uconst with one operand set to zero.
+
+ Sometimes the data member location may also be negative. In yet some
other
+ cases (specifically union data members), the data member location is
+ non-existent. Handle all these scenarios here to abstract this. */
+
+static HOST_WIDE_INT ctf_get_AT_data_member_location (dw_die_ref die)
likewise.
+{
+ HOST_WIDE_INT field_location = 0;
+ dw_attr_node * attr;
+
+ /* The field location (in bits) can be determined from
+ either a DW_AT_data_member_location attribute or a
+ DW_AT_data_bit_offset attribute. */
+ if (get_AT (die, DW_AT_data_bit_offset))
+field_location = get_AT_unsigned (die, DW_AT_data_bit_offset);
+ else
+{
+ attr = get_AT (die, DW_AT_data_member_location);
+ if (attr && AT_class (attr) == dw_val_class_loc)
+ {
+ dw_loc_descr_ref descr = AT_loc (attr);
+ /* Operand 2 must be zero; the structure is assumed to be on the
+stack in DWARF2. */
+ gcc_assert (!descr->dw_loc_oprnd2.v.val_unsigned);
+ gcc_assert (descr->dw_loc_oprnd2.val_class
+ == dw_val_class_unsigned_const);
+ field_location = descr->dw_loc_oprnd1.v.val_unsigned;
+ }
+ else
+ {
+ attr = get_AT (die, DW_AT_data_member_location);
+ if (attr && AT_class (attr) == dw_val_class_const)
+ field_location = AT_int (attr);
+ else
+ field_location = (get_AT_unsigned (die,
+ DW_AT_data_member_location)
+ * 8);
+ }
+}
so when neither of the above we return 0? Maybe we should ICE here
instead. Ada for example has variable location fields.
Yes, adding gcc_unreachable is sensible. Will do.
Hmm... I have to correct myself and say that we should not ICE here when
neither DW_AT_data_bit_offset nor DW_AT_data_member_location attributes
are available. There are valid C constructs when we will hit that case.
For these cases, we piggyback on the get_AT_unsigned () API as it
returns 0 when the requested attribute is NULL.
union c
{
int c1;
int c2;
} my_u_c;
DIE0: DW_TAG_union_type (0x70f49190)
abbrev id: 0 offset: 0 mark: 0
DW_AT_name: "c"
DW_AT_byte_size: 4
DW_AT_decl_file: "test-union-1.c" (0)
DW_AT_decl_line: 8
DW_AT_decl_column: 7
DIE0: DW_TAG_member (0x70f491e0)
abbrev id: 0 offset: 0 mark: 0
DW_AT_name: "c1"
DW_AT_decl_file: "test-union-1.c" (0)
DW_AT_decl_line: 10
DW_AT_decl_column: 7
DW_AT_type: die -> 0 (0x70f49230)
DIE0: DW_TAG_member (0x70f49280)
abbrev id: 0 offset: 0 mark: 0
DW_AT_name: "c2"
DW_AT_decl_file: "test-union-1.c" (0)
DW_AT_decl_line: 11
DW_AT_decl_column: 7
DW_AT_type: die -> 0 (0x70f49230)
As for Ada, CTF is not supported.
So I think we are OK here.
Overall I think this is fine with the suggested changes. You may want
to refactor the debug info kind into a flag based one (I've seen you
suggested that on IRC).
Richard.
Thanks again for reviewing. Yes, I have started tinkering around to make the
write_symbols into a
[PATCH 2/2] dwarf: new dwarf_debuginfo_p predicate
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
gcc/c-family/ChangeLog:
* c-lex.c (init_c_lex): Use dwarf_debuginfo_p.
gcc/ChangeLog:
* config/c6x/c6x.c (c6x_output_file_unwind): Use dwarf_debuginfo_p.
* dwarf2cfi.c (cfi_label_required_p): Likewise.
(dwarf2out_do_frame): Likewise.
* final.c (dwarf2_debug_info_emitted_p): Likewise.
(final_scan_insn_1): Likewise.
* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* targhooks.c (default_debug_unwind_info): Use dwarf_debuginfo_p.
* toplev.c (process_options): Likewise.
---
gcc/c-family/c-lex.c | 4 ++--
gcc/config/c6x/c6x.c | 3 +--
gcc/dwarf2cfi.c | 9 -
gcc/final.c | 15 ++-
gcc/flags.h | 4
gcc/opts.c | 8
gcc/targhooks.c | 2 +-
gcc/toplev.c | 6 ++
8 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 6374b72..5174b22 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3. If not see
#include "stor-layout.h"
#include "c-pragma.h"
#include "debug.h"
+#include "flags.h"
#include "file-prefix-map.h" /* remap_macro_filename() */
#include "langhooks.h"
#include "attribs.h"
@@ -87,8 +88,7 @@ init_c_lex (void)
/* Set the debug callbacks if we can use them. */
if ((debug_info_level == DINFO_LEVEL_VERBOSE
- && (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG))
+ && dwarf_debuginfo_p ())
|| flag_dump_go_spec != NULL)
{
cb->define = cb_define;
diff --git a/gcc/config/c6x/c6x.c b/gcc/config/c6x/c6x.c
index f9ad1e5..a10e2f8 100644
--- a/gcc/config/c6x/c6x.c
+++ b/gcc/config/c6x/c6x.c
@@ -439,8 +439,7 @@ c6x_output_file_unwind (FILE * f)
{
if (flag_unwind_tables || flag_exceptions)
{
- if (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG)
+ if (dwarf_debuginfo_p ())
asm_fprintf (f, "\t.cfi_sections .debug_frame, .c6xabi.exidx\n");
else
asm_fprintf (f, "\t.cfi_sections .c6xabi.exidx\n");
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 362ff3f..c27ac19 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -39,7 +39,7 @@ along with GCC; see the file COPYING3. If not see
#include "expr.h" /* init_return_column_size */
#include "output.h"/* asm_out_file */
#include "debug.h" /* dwarf2out_do_frame, dwarf2out_do_cfi_asm */
-
+#include "flags.h" /* dwarf_debuginfo_p */
/* ??? Poison these here until it can be done generically. They've been
totally replaced in this file; make sure it stays that way. */
@@ -2289,8 +2289,7 @@ cfi_label_required_p (dw_cfi_ref cfi)
if (dwarf_version == 2
&& debug_info_level > DINFO_LEVEL_TERSE
- && (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG))
+ && dwarf_debuginfo_p ())
{
switch (cfi->dw_cfi_opc)
{
@@ -3557,9 +3556,9 @@ bool
dwarf2out_do_frame (void)
{
/* We want to emit correct CFA location expressions or lists, so we
- have to return true if we're going to output debug info, even if
+ have to return true if we're going to generate debug info, even if
we're not going to output frame or unwind info. */
- if (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG)
+ if (dwarf_debuginfo_p ())
return true;
if (saved_do_cfi_asm > 0)
diff --git a/gcc/final.c b/gcc/final.c
index ba4285d..794702f 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1428,7 +1428,8 @@ asm_str_count (const char *templ)
static bool
dwarf2_debug_info_emitted_p (tree decl)
{
- if (write_symbols != DWARF2_DEBUG && write_symbols != VMS_AND_DWARF2_DEBUG)
+ /* When DWARF2 debug info is not generated internally. */
+ if (!dwarf_debuginfo_p ())
return false;
if (DECL_IGNORED_P (decl))
@@ -2298,10 +2299,8 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int
optimize_p ATTRIBUTE_UNUSED,
break;
case NOTE_INSN_BLOCK_BEG:
- if (debug_info_level == DINFO_LEVEL_NORMAL
- || debug_info_level == DINFO_LEVEL_VERBOSE
- || write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG
+ if (debug_info_level >= DINFO_LEVEL_NORMAL
+ || dwarf_debuginfo_p ()
|| write_symbols == VMS_DEBUG)
{
int n = BLOCK_NUMBER (NOTE_BLOCK (insn));
@@ -2336,10 +2335,8 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int
optimize_p ATTRIBUTE_UNUSED,
case NOTE_INSN_BLOCK_END:
maybe_output_next_view (seen);
- if (debug_info_level == DINFO_LEVEL_NORMAL
-
[PATCH 1/2] opts: change write_symbols to support bitmasks
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
gcc/c-family/ChangeLog:
* c-opts.c (c_common_post_options): Adjust access to debug_type_names.
* c-pch.c (struct c_pch_validity): Use type uint32_t.
(pch_init): Renamed member.
(c_common_valid_pch): Adjust access to debug_type_names.
gcc/ChangeLog:
* common.opt: Change type to support bitmasks.
* flag-types.h (enum debug_info_type): Rename enumerator constants.
(NO_DEBUG): New bitmask.
(DBX_DEBUG): Likewise.
(DWARF2_DEBUG): Likewise.
(XCOFF_DEBUG): Likewise.
(VMS_DEBUG): Likewise.
(VMS_AND_DWARF2_DEBUG): Likewise.
* flags.h (debug_set_to_format): New function declaration.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
* opts.c (debug_type_masks): Array of bitmasks for debug formats.
(debug_set_to_format): New function definition.
(debug_set_count): Likewise.
(debug_set_names): Likewise.
(set_debug_level): Update access to debug_type_names.
* toplev.c: Likewise.
gcc/objc/ChangeLog:
* objc-act.c (synth_module_prologue): Use uint32_t instead of enum
debug_info_type.
---
gcc/c-family/c-opts.c | 10 +++--
gcc/c-family/c-pch.c | 12 +++---
gcc/common.opt| 2 +-
gcc/flag-types.h | 29 ++
gcc/flags.h | 17 +++-
gcc/objc/objc-act.c | 2 +-
gcc/opts.c| 109 +-
gcc/toplev.c | 9 +++--
8 files changed, 158 insertions(+), 32 deletions(-)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 89e05a4..e463240 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -1112,9 +1112,13 @@ c_common_post_options (const char **pfilename)
/* Only -g0 and -gdwarf* are supported with PCH, for other
debug formats we warn here and refuse to load any PCH files. */
if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
- warning (OPT_Wdeprecated,
-"the %qs debug format cannot be used with "
-"pre-compiled headers", debug_type_names[write_symbols]);
+ {
+ gcc_assert (debug_set_count (write_symbols) <= 1);
+ warning (OPT_Wdeprecated,
+ "the %qs debug format cannot be used with "
+ "pre-compiled headers",
+ debug_type_names[debug_set_to_format (write_symbols)]);
+ }
}
else if (write_symbols != NO_DEBUG && write_symbols != DWARF2_DEBUG)
c_common_no_more_pch ();
diff --git a/gcc/c-family/c-pch.c b/gcc/c-family/c-pch.c
index fd94c37..6804388 100644
--- a/gcc/c-family/c-pch.c
+++ b/gcc/c-family/c-pch.c
@@ -52,7 +52,7 @@ enum {
struct c_pch_validity
{
- unsigned char debug_info_type;
+ uint32_t pch_write_symbols;
signed char match[MATCH_SIZE];
void (*pch_init) (void);
size_t target_data_length;
@@ -108,7 +108,7 @@ pch_init (void)
pch_outfile = f;
memset (&v, '\0', sizeof (v));
- v.debug_info_type = write_symbols;
+ v.pch_write_symbols = write_symbols;
{
size_t i;
for (i = 0; i < MATCH_SIZE; i++)
@@ -252,13 +252,15 @@ c_common_valid_pch (cpp_reader *pfile, const char *name,
int fd)
/* The allowable debug info combinations are that either the PCH file
was built with the same as is being used now, or the PCH file was
built for some kind of debug info but now none is in use. */
- if (v.debug_info_type != write_symbols
+ if (v.pch_write_symbols != write_symbols
&& write_symbols != NO_DEBUG)
{
+ gcc_assert (debug_set_count (v.pch_write_symbols) <= 1);
+ gcc_assert (debug_set_count (write_symbols) <= 1);
cpp_warning (pfile, CPP_W_INVALID_PCH,
"%s: created with -g%s, but used with -g%s", name,
- debug_type_names[v.debug_info_type],
- debug_type_names[write_symbols]);
+ debug_type_names[debug_set_to_format (v.pch_write_symbols)],
+ debug_type_names[debug_set_to_format (write_symbols)]);
return 2;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index a75b44e..ffb968d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -109,7 +109,7 @@ bool exit_after_options
; flag-types.h for the definitions of the different possible types of
; debugging information.
Variable
-enum debug_info_type write_symbols = NO_DEBUG
+uint32_t write_symbols = NO_DEBUG
; Level of debugging information we are producing. See flag-types.h
; for the definitions of the different possible levels.
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index a038c8f..d60bb30 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -24,15 +24,30 @@ along with GCC; see the file COPYING3. If not see
enum debug_info_type
[PATCH 0/2] Fix write_symbols for supporting multiple debug formats
Hello, Over the last year, we have discussed and agreed that in order to support multiple debug formats, we keep DWARF as the default internal debug format; Any new debug format to be supported feeds off DWARF dies. This requirement specification has worked well for addition for CTF/BTF overall. There are some existing issues that need to discussed and fixed in this regard, however. One of them is the definition and handling of write_symbols. The current issue is that write_symbols is defined as enum debug_info_type write_symbols = NO_DEBUG; This means any new combination of debug formats needs to be explicitly enumerated, like CTF_AND_DWARF2_DEBUG, VMS_AND_DWARF2_DEBUG etc. So to support say, "-gctf -gbtf -g" or to make other combinations of debug formats possible, each one needs to spelled out explicitly; this will make the handling ugly. We discussed over IRC about the possibility of write_symbols to use bitmasks instead. Please take a look at the patch set and let me know what you think. BTW, the patch 2/2 [dwarf: new dwarf_debuginfo_p predicate] in this series is the same as the one sent earlier in the CTF patch series (and has been approved). I just include it in this patch series as it fits better here. In a subsequent patch after these current two patches, I can work on removing the VMS_AND_DWARF2_DEBUG symbol and replacing its usages with the appropriate bitmasks. I would also like to review the usages of debug_type_names [] in code diagnostics around PCH (in c-family/c-opts.c and c-family/c-pch.c) in terms of what combination of debug formats would be allowed and such. But at this time, the patch retains the current behaviour by simply adjusting the approach to access the debug_type_name []. Boostrapped and regression tested on x86_64. Thanks, Indu Bhagat (2): opts: change write_symbols to support bitmasks dwarf: new dwarf_debuginfo_p predicate gcc/c-family/c-lex.c | 4 +- gcc/c-family/c-opts.c | 10 +++-- gcc/c-family/c-pch.c | 12 +++--- gcc/common.opt| 2 +- gcc/config/c6x/c6x.c | 3 +- gcc/dwarf2cfi.c | 9 ++-- gcc/final.c | 15 +++ gcc/flag-types.h | 29 ++--- gcc/flags.h | 21 - gcc/objc/objc-act.c | 2 +- gcc/opts.c| 117 +- gcc/targhooks.c | 2 +- gcc/toplev.c | 15 --- 13 files changed, 186 insertions(+), 55 deletions(-) -- 1.8.3.1
Re: [PATCH V7 4/7] CTF/BTF debug formats
On 4/29/21 1:02 PM, Indu Bhagat wrote:
+{
+ dw_die_ref c;
+
+ if (!ctf_do_die (die))
+ return;
+
+ FOR_EACH_CHILD (die, c, ctf_do_die (c));
+}
+
/* Perform any cleanups needed after the early debug generation pass
has run. */
@@ -32471,6 +32491,16 @@ dwarf2out_early_finish (const char *filename)
print_die (comp_unit_die (), dump_file);
}
+ /* Generate CTF debug info. */
+ if ((ctf_debug_info_level > CTFINFO_LEVEL_NONE
+ || btf_debug_info_level > BTFINFO_LEVEL_NONE) && lang_GNU_C ())
+ {
+ ctf_debug_init ();
+ debug_format_do_cu (comp_unit_die ());
+ for (limbo_die_node *node = limbo_die_list; node; node =
node->next)
+ debug_format_do_cu (node->die);
+ }
+
Since you have support to copy .ctf sections for LTO you have to write
those here. And you have to care for fat LTO objects which for dwarf
results in two sets of .debug_info - I suppose for CTF you can share
the section for the fat and the LTO part though? So why are you
writing the CFT debug in dwarf2out_finish now?
The change to writing CTF/BTF debug information in dwarf2out_finish
instead of dwarf2out_early_finish, at this time, was driven by the needs
of BTF. A BTF section has entries of kind BTF_KIND_DATASEC which
essentially give information about which section a variable is in (.bss,
.rodata, .text). This information is available later on in the
compilation process and hence, BTF needed a longer lifetime of the CTF
container to update the information in the CTF container. In general,
keeping any future needs that may come up, it seemed like a better
design point to defer the ctf_debug_finalize to dwarf2out_finish
(assuming we work out it out with LTO).
Umm..what I wrote wrt BTF was incorrect. The larger lifetime of CTF
container is currently needed specifically for the BPF CO-RE
relocations. They will be generated in the BPF backend, but only at
'expand' time, which is much later than when dwarf2out_early_finish
happens. Strictly speaking, for BTF only (without BPF CO-RE support,
which will go in .BTF.ext) it is not necessary.
Can you elaborate on what it means to say "we have two sets of
.debug_info for fat LTO objects" ?
I am also lost a bit by the comment on "share the section for the fat
and LTO part though". If it helps, from what I can reason, I can add
that I do not see how in LTO mode, the CTF of a compilation unit will
shift at all between the compile phase and the LTO phase. This should be
true for CTF V3 atleast. But for V4, this may not be true...
For a moment, for the sake of this question, if we establish that
CTF/BTF generation always feeds off DWARF DIEs (so there is no need to
access type/decl tree nodes), what will it take to keep LTO support
while keeping ctf_debug_finalize in dwarf2out_finish ?
Re: [PATCH V7 4/7] CTF/BTF debug formats
Hello,
On 4/29/21 5:10 AM, Richard Biener wrote:
On Thu, 29 Apr 2021, Jose E. Marchesi wrote:
This commit introduces support for generating CTF debugging
information and BTF debugging information from GCC.
Comments inline.
Thanks for your reviews.
My responses and questions inline at respective points.
Indu
+void
+btf_finalize (void)
+{
+ btf_info_section = NULL;
+
+ /* Clear preprocessing state. */
+ num_vars_added = 0;
+ holes.release ();
+ voids.release ();
+ funcs.release ();
+ for (size_t i = 0; i < datasecs.length (); i++)
+datasecs[i].entries.release ();
+ datasecs.release ();
+
+ ggc_free (btf_var_ids);
I think you want to NULL btf_var_ids after this.
ACK. Will take care of this and the other comments' occurences in btfout.c.
diff --git a/gcc/ctfc.h b/gcc/ctfc.h
new file mode 100644
index 000..092faa0b2c3
--- /dev/null
+++ b/gcc/ctfc.h
@@ -0,0 +1,413 @@
+/* ctfc.h - Declarations and definitions related to the CTF container.
+ Copyright (C) 2019,2021 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+
