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 t
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.
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
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 difficul
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/MAI
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.
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/
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 sup
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 identifin
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
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
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_GLOBA
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
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 appr
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
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_as
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
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
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)
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 varia
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 va
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, gc
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
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 exter
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(-)
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
[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/ctf
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 Form
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
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 emp
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
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 front
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 pa
/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
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
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
-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 l
[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
d
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.
/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
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
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 _n
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
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
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
-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 li
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 relocatio
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 debu
[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 useca
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 debu
-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 li
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 wit
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 relocatio
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_fina
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
dwar
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/B
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
--
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
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 defau
[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 t
[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 testin
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 te
[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 usin
[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 th
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/Chan
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
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
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
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
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
[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)
[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/ChangeL
[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. U
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
[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 wri
[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-fami
[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 a
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
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.
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.
* dw
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.
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.
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
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 resp
84 matches
Mail list logo
