On 6/24/24 09:11, David Faust wrote:
Ping.
Richard: I changed the option name as you asked but forgot to CC you on
the updated patch. Is the new option OK?
Indu: You had some minor comments on the prior version which I have
addressed, not sure whether you meant the rest of the patch was OK or
On 5/30/24 14:32, David Faust wrote:
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patches, in particular the
guarantee
On 5/30/24 14:32, David Faust wrote:
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have
On 5/30/24 14:32, David Faust wrote:
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated
On 5/30/24 14:32, David Faust wrote:
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process
On 5/30/24 14:32, David Faust wrote:
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
On 5/30/24 14:32, David Faust wrote:
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even
On 5/2/24 10:11, David Faust wrote:
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have
On 5/2/24 10:11, David Faust wrote:
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from
On 5/2/24 10:11, David Faust wrote:
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process
On 5/2/24 10:11, David Faust wrote:
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
On 5/2/24 10:11, David Faust wrote:
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even
On 4/11/24 14:02, David Faust wrote:
This patch fixes a small error that could occur in the debug comment
when emitting a type reference with btf_asm_type_ref.
While working on a previous patch, I noticed the following in the asm
output for the test btf-bitfields-4.c:
...
.long
On 4/11/24 14:01, David Faust wrote:
[Changes from v1: use btf_dmd_representable_bitfield_p in
btf_asm_sou_member, instead of a slightly incorrect equivalent check.]
This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be
On 4/11/24 11:53, David Faust wrote:
This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF. It is undefined what should happen in such cases, but we can
at least do something reasonable.
Commit
PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in a
struct and -gctf1
The CTF generation in GCC does not have a mechanism to roll-back an
already added type. In this testcase presented in the PR, we hit a
representation limit in CTF slices (for a member of a struct)
Hi,
The patch series includes two patches: first one is a fix for PR
debug/112878 and the second one is for an existing BTF generation issue.
Testing Notes:
- Regression tested on x86_64-linux-gnu
- Tested btf.exp, ctf.exp, bpf.exp for --target=bpf-unknown-none
Thanks,
Indu Bhagat (2):
ctf
Testing the previous fix in gen_ctf_sou_type () reveals an issue in BTF
generation, however: BTF emission was currently decrementing the vlen
(indicating the number of members) to skip members of type CTF_K_UNKNOWN
altogether, but still emitting the BTF for the corresponding member (in
On 4/8/24 2:01 PM, David Faust wrote:
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT
On 4/8/24 12:26, David Faust wrote:
The behavior introduced in
fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.
is only fully correct when compiling for the BPF target with BPF CO-RE
enabled. In other cases, depending on optimizations, it can result in
an incorrect symbol
dimensions. The CTF processing was
so far working through them in the opposite (incorrect) order.
While fixing the issue, refactor the code a bit for readability.
co-authored-By: Indu Bhagat
gcc/
PR debug/114186
* dwarf2ctf.cc (gen_ctf_array_type): Invoke the ctf_add_array
in the opposite (incorrect) order.
While fixing the issue, refactor the code a bit for readability.
co-authored-By: Indu Bhagat
gcc/
PR debug/114186
* dwarf2ctf.cc (gen_ctf_array_type): Invoke the ctf_add_array ()
in the correct order of the dimensions
On 3/1/24 11:01, David Faust wrote:
The array member of struct SFOO in the ctf-file-scope-1 caused the test
to fail for the BPF target, since BPF does not support dynamic stack
allocation. The array does not need to variable length for the sake of
the test, so make it fixed length instead to
On 12/12/23 14:35, David Faust wrote:
The BTF specification does not formally define a representation for
forward-declared enum types such as:
enum Foo;
Forward-declarations for struct and union types are represented by
BTF_KIND_FWD, which has a 1-bit flag distinguishing the two.
The
On 12/5/23 13:45, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 01:36:30PM -0800, Indu Bhagat wrote:
To resolve the issue of combined Binutils (2.41) + GCC (13) failing to
install (https://sourceware.org/bugzilla/show_bug.cgi?id=31108), we will
need some backports. This specific issue
As noted in PR libsframe/30014 - FTBFS: install-strip fails because
bfdlib relinks and fails to find libsframe, the install time
dependencies of libbfd need to be updated.
ChangeLog:
* Makefile.def: Reflect that libsframe needs to installed before
libbfd. Reorder a bit to better
The linker merges all the input .sframe sections. When merging, the
linker verifies that all the input .sframe sections have the same
abi/arch.
The linker uses libsframe library to perform key actions on the
.sframe sections - decode, read, and create output data. This
implies buildsystem
-*
dependencies in the top-level makefiles.
I think it makes sense to bring both of the following two commits (from
the trunk) to the GCC13 branch:
commit eff0e7a4ae31d1e4e64ae37bbc10d073d8579255
Author: Indu Bhagat
Date: Wed Jan 18 23:17:49 2023 -0800
toplevel: Makefile.def
On 12/4/23 15:47, David Faust wrote:
The process of creating BTF_KIND_DATASEC records involves iterating
through variable declarations, determining which section they will be
placed in, and creating an entry in the appropriate DATASEC record
accordingly.
For variables without e.g. an explicit
PR debug/112656 - btf: function prototypes generated with name
With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
generated BTF section.
As noted in the discussion in the bugzilla, the number of
BTF_KIND_FUNC_PROTO types output varies across targets (BPF with -mco-re
vs
PR debug/112768 - btf: fix asm comment output for BTF_KIND_FUNC* kinds
The patch adds a small function to abstract out the detail and return
the name of the type. The patch also fixes the issue of BTF_KIND_FUNC
appearing in the comments with a 'null' string.
For btf-function-6.c testcase, after
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
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)
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
/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
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
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
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
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
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
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.
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
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
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
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,
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.
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
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
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 de
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
-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.
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
t 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_var
[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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
k 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 -mc
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
-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
l-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 +
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
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
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
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,
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
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
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
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
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
.
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
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
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
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
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
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
/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
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
1 - 100 of 175 matches
Mail list logo
