On 2025-05-01 2:34 p.m., Bruce McCulloch wrote:
Currently, there is a check in gen_ctf_array_type that prevents GNU vectors
generated by the vector attribute from being emitted (e.g. typedef int v8si
__attribute__ ((vector_size (32)));). Because this check happens in
dwarf2ctf.cc, this prevents G
uils and GDB have already accepted
initial CTF support). The other dimension is a user friendly workflow which
supports current users and eases further adoption and growth.
Indu
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 allo
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
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
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 referenc
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 generate
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
output_asm_b
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
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) an
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
936dd627cd
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 repres
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 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 de-fac
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
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 non-BPF
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 __
-*
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
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 change
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
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 is with
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 irrev
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.
Th
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 o
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 from
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 suffici
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 that
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/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 irreve
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.
Thi
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 of
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 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 sufficie
it's not clear to me how .debug_types integration
with split-dwarf works out. If the linker does not see the
non-relocation-necessary part of the DWARF, I am not sure how .debug_type
type
units are de-duplicated when using split-dwarf.
Thanks
Indu
On 10/07/2019 12:35 AM, Richard Biener wrote:
On Fri, Oct 4, 2019 at 9:12 PM Indu Bhagat wrote:
Hello,
At GNU Tools Cauldron this year, some folks were curious to know more on how
the "type representation" in CTF compares vis-a-vis DWARF.
[...]
So, for the small C testcase wi
On 10/08/2019 08:37 AM, Pedro Alves wrote:
On 10/4/19 8:23 PM, Indu Bhagat wrote:
Hello,
At GNU Tools Cauldron this year, some folks were curious to know more on how
the "type representation" in CTF compares vis-a-vis DWARF.
I was one of those, and I brought this up to Jose,
to have a larger
footprint than CTF (with 50% of .debug_str accounted for).
Indu
qualified type variants. But maybe
CTF just has a more compact representation for the bits it actually implements.
Richard.
CTF represents typedefs and qualified type variants. They are included in the
the .ctf section sizes above.
Indu
In section "-Wformat-overflow=1", following is stated :
void f (int a, int b)
{
char buf [12];
sprintf (buf, "a = %i, b = %i\n", a, b);
}
" Increasing the size of the buffer by a single byte is sufficient to avoid
the warning,"
[size of an unknown int for the purpose of this warning is = 1
ompilation unit or a function when using
-fprofile-use.
The flag is on by default when -fprofile-use is specified and generates errors
by default (like -Wcoverage-mismatch).
The attachment pr86957-missing-profile-diagnostic shows the behavior of GCC
with the patch.
T
tic-2 shows the warning messages
3. Added a testcase for warning in the case of missing profile feedback data
file for a compilation unit
Thanks
gcc/ChangeLog:
2018-09-14 "Indu Bhagat"
* common.opt: New warning option -Wmissing-profile.
* coverage.c (get_covera
On 09/17/2018 03:52 AM, Jan Hubicka wrote:
On 09/11/2018 02:21 AM, Martin Liška wrote:
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -811,6 +811,10 @@ Wcoverage-mismatch
Common Var(warn_coverage_mismatch) Init(1) Warning
Warn in case profiles in -fprofile-use do not match.
+Wmissing-prof
Attached is the refreshed patch for trunk.
After commit 264462 (Remove arc profile histogram in non-LTO mode.), the API
of get_coverage_counts was changed a bit. So the main difference between the
current version of my patch from the previous one is that :
Now I use
+ if (counter == GCOV_CO
Done. Attached is updated patch.
Patch is tested on x86_64
Thanks
On 09/24/2018 09:37 AM, Martin Sebor wrote:
I would suggest to use the term "remove" or "delete" instead of
the informal "wipe out" when referring to removing files or their
contents.
Martin
diff --git a/gcc/common.opt b/gc
In function minmax_replacement in tree-ssa-phiopt.c, MIN_EXPR/MAX_EXPR
are substituted for when the following condition is false - (HONOR_NANS
(type) || HONOR_SIGNED_ZEROS (type)). So for FP mode, this is false when
_both_ of the following conditions are fulfilled : 1. flag_signed_zeros
is zero
Thanks for your feedback. Comments inline.
On 05/21/2019 03:28 AM, Richard Biener wrote:
GCC RFC patch set :
Patch 1 is a simple addition of a new function lang_GNU_GIMPLE to check for
GIMPLE frontend.
I don't think you should need this - the GIMPLE "frontend" is intended for
unit testing only
On 05/22/2019 02:04 AM, Richard Biener wrote:
The CTF debug information is kept in a CTF container distinct from the frontend
structures. HashMaps are used to avoid generation of duplicate CTF and to
book-keep the generated CTF.
OK. So I wonder how difficult it is to emit CTF by walking dwa
Hi Michael,
On 05/24/2019 06:04 AM, Michael Matz wrote:
Hello,
On Thu, 23 May 2019, Indu Bhagat wrote:
OK. So I wonder how difficult it is to emit CTF by walking dwarf2outs own
data structures? That is, in my view CTF should be emitted by
dwarf2out_early_finish () (which is also the point
ed across type units ?
Thanks!
Indu
On 05/29/2019 12:15 AM, Richard Biener wrote:
Of course. We are merely discussing of where the triggering of processing
starts: debug hooks, or something like:
dwarf2out_early_finish() {
...
if (ctf)
ctf_emit();
}
(and then in addition if the current DWARF info would be the so
Hello,
On 05/24/2019 06:24 AM, Jakub Jelinek wrote:
On Tue, May 21, 2019 at 03:44:47PM -0700, Indu Bhagat wrote:
Yes and No :) And that is indeed one of the motivation of the project - to
allow CTF generation where it's most suited aka the toolchain.
There do exist utilties for generati
[Changes from V1]
None
gcc/ChangeLog:
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h: New Prototype.
---
gcc/ChangeLog | 5 +
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhoo
can be
used by dynamic tracers like DTrace.
-- Patch 3 initializes the CTF container if user-level option for CTF
generation is specified. CTF is generated for all to-be-emitted global
decls if gtLEVEL of 2 is specified.
Tested on x86_64-linux and sparc64-linux.
Thanks
Indu Bhagat
-gtLEVEL is used to request CTF debug information and also to specify how much
CTF debug information.
[Changes from V1]
None
gcc/ChangeLog:
* common.opt: Add CTF debug info options.
* doc/invoke.texi: Document the CTF debug info options.
* flag-types.h (enum ctf_debug_
Initialize CTF container when -gtLEVEL is specified. Generate CTF debug info
for global decls. Import the CTF header from binutils.
[Changes from V1]
- Instead of using the debug hooks infrastructure, the generation and
emission of CTF is done by exposing the CTF APIs to the rest of the
c
Hello,
PING, In case this patch series slipped your attention.
Thanks
Indu
On Wed, Jun 12, 2019 at 10:50 AM Indu Bhagat wrote:
>
> Hello,
>
> Thanks for the feedback on the previous patch set.
>
> This is the second posting of the RFC patch for CTF support in GCC. This pa
On 06/18/2019 12:24 PM, Bernhard Reutner-Fischer wrote:
On 12 June 2019 20:00:09 CEST, Indu Bhagat wrote:
-gtLEVEL is used to request CTF debug information and also to specify
how much
CTF debug information.
The option name is way too generic IMO.
-gctfLEVEL or some such would at least
This regression slipped in because my testing was a week old. The
predict-22.c is a commit of Nov 28.
Thanks Jeff. I saw this regression yesterday and was about to send the
patch shortly.
I should have kept the patch tested proactively.
Thanks
Indu
On 12/01/2018 08:56 AM, Jeff Law wrote
On 12/05/2018 03:33 AM, Thomas Schwinge wrote:
Hi!
Sorry for my late follow-up; had a lot of catch up to do back then.
On Thu, 27 Sep 2018 11:47:31 +0200, Richard Biener
wrote:
On Mon, Sep 24, 2018 at 9:14 PM Indu Bhagat wrote:
Done. Attached is updated patch.
Patch is tested on x86_64
On 12/06/2018 05:54 PM, Indu Bhagat wrote:
2. I do however see other tests (a total of 23) which are have
regressed from
PASS --> UNRESOLVED. A diff is attached.
Each one of them is due to "Error/Warning threshold exceeded: 1 0
(max. 1 3)"
False alarm.
Looks like
gcc/ChangeLog:
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h: New Prototype.
---
gcc/ChangeLog | 5 +
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
index 89fb5bc..66daa9
Initialize CTF container when -gtLEVEL is specified. Generate CTF debug info
for global decls. Import the CTF header from binutils.
gcc/ChangeLog:
* Makefile.in: Add ctfout.* files to GTFILES.
* cgraphunit.c (symbol_table::finalize_compilation_unit): Generate CTF
debug
-gtLEVEL is used to request CTF debug information and also to specify how much
CTF debug information.
gcc/ChangeLog:
* common.opt: Add CTF debug info options.
* doc/invoke.texi: Document the CTF debug info options.
* flag-types.h (enum ctf_debug_info_levels): New enum.
online to talk about the CTF support in GNU toolchain at
Cauldron 2019. Posting these patches so that there is added context.
Testing :
Apart from the usual bootstrap and regression testing on x86_64/linux,
sparc64/linux, I have now compiled more codebases with -gt.
Thanks
Indu Bhagat (6):
Add
[Changes from V4]
Added new testcases
- gcc.dg/debug/ctf/ctf-bitfields-3.c
- gcc.dg/debug/ctf/ctf-bitfields-4.c
- gcc.dg/debug/ctf/ctf-cvr-quals-4.c
- gcc.dg/debug/ctf/ctf-forward-3.c
- gcc.dg/debug/ctf/ctf-function-pointers-2.c
gcc/testsuite/ChangeLog:
* gcc.dg/debug/ctf/ctf-2.c: Ne
libiberty/ChangeLog:
* simple-object.c (handle_lto_debug_sections): Copy CTF section.
---
libiberty/ChangeLog | 5 +
libiberty/simple-object.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/libiberty/simple-object.c b/libiberty/simple-object.c
index b00c265..96bdcf8 10
For each translation unit, a CTF container (ctf_container_t) is used to
keep the CTF debug info.
- ctfout.c hosts the compiler facing routines for CTF generation and emission.
- ctfcreate.c contains the CTF format specific CTF creation routines.
- ctfutils.c contains helper routines for CTF creati
I have been looking at -fdump-ipa-profile dump with an intention to sanitize
bits of information so that one may use it to judge the "quality of a profile"
in FDO.
The overall question I want to address is - are there ways to know which
functions were not run in the training run, i.e. have ZERO p
Changelog entry attached. Sorry about that.
Comments inline.
Thanks
On 11/09/2018 04:23 PM, Jeff Law wrote:
On 11/7/18 5:49 PM, Indu Bhagat wrote:
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 599a3bb..7595e6c 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -358,7 +358,7
On 11/12/2018 01:48 AM, Martin Liška wrote:
make check-gcc on x86_64 shows no new failures.
(A related PR washttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 where we
added diagnostics for the NO PROFILE case.)
Hi.
Thanks for the patch. I'm not a maintainer, but the idea of the patch loo
-gtLEVEL is used to request CTF debug information and also to specify how much
CTF debug information.
gcc/ChangeLog :
* common.opt: Add CTF debug info options.
* doc/invoke.texi: Document the CTF debug info options.
* flag-types.h (enum ctf_debug_info_levels): New enum.
gcc/ChangeLog:
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h: New Prototype.
---
gcc/ChangeLog | 5 +
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
index 2df97f2..f3a64
Initialize CTF container when -gtLEVEL is specified. Generate CTF debug info
for global decls. Import the CTF header from binutils.
gcc/ChangeLog :
* Makefile.in: Add ctfout.* files to GTFILES.
* cgraphunit.c (symbol_table::finalize_compilation_unit): Generate CTF
debug
info are in the works
and will be upstreamed soon.
In the subsequent patches, I intend to close some open ends in the current
patch and add LTO support.
Thanks,
Indu Bhagat (5):
Add new function lang_GNU_GIMPLE
Add CTF command line options : -gtLEVEL
Setup for CTF generation and emi
gcc/testsuite/ChangeLog :
* gcc.dg/debug/ctf/ctf-2.c: New test.
* gcc.dg/debug/ctf/ctf-anonymous-struct-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-anonymous-union-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-array-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-bitfields-1.c: L
For each translation unit, a CTF container (ctf_container_t) is used to
keep the CTF debug info.
- ctfout.c hosts the compiler facing routines for CTF generation and emission.
- ctfcreate.c contains the CTF format specific CTF creation routines.
- ctfutils.c contains helper routines for CTF creati
Ping.
Can someone please review these patches ? We would like to get the
support for CTF integrated soon.
Thanks
Indu
On Wed, Jun 26, 2019 at 11:38 PM Indu Bhagat wrote:
>
> Hello,
>
> This patch series adds support for CTF generation in GCC.
>
> [Changes from V2]
> - P
On 07/02/2019 08:18 PM, Jeff Law wrote:
On 7/2/19 11:54 AM, Indu Bhagat wrote:
Ping.
Can someone please review these patches ? We would like to get the
support for CTF integrated soon.
I'm not sure there's really even consensus that we want CTF support in
GCC. Though I thin
On 07/03/2019 05:31 AM, Richard Biener wrote:
On Wed, Jul 3, 2019 at 5:18 AM Jeff Law wrote:
On 7/2/19 11:54 AM, Indu Bhagat wrote:
Ping.
Can someone please review these patches ? We would like to get the
support for CTF integrated soon.
I'm not sure there's really even consens
On 07/04/2019 03:43 AM, Richard Biener wrote:
On Thu, Jul 4, 2019 at 2:36 AM Indu Bhagat wrote:
[...]
RE subset of C : It is true that CTF format currently does leave out a very
small subset of C like FIXED_POINT as you noted ( CTF does have representation
for COMPLEX_TYPE, if my code paths
with
GCC 4.8.5 and GCC 8 and later, for now. )
The infrastructure is quite old but you'd need new invocation hooks so this
won't help.
OK then. I will continue to focus on my current implementation without
exploring the plugin option at this time. Thanks for confirming.
Indu
Initialize CTF container when -gtLEVEL is specified. Generate CTF debug info
for global decls. Import the CTF header from binutils.
[Changes from V3]
Inform the user instead of warning if -gtLEVEL is used and the frontend is not
C.
gcc/ChangeLog:
* Makefile.in: Add ctfout.* files to G
/binutils/2019-07/msg00159.html. This current GCC
patch set has the ctf.h in sync with the afore-mentioned binutils patch set. )
Thanks
Indu Bhagat (5):
Add new function lang_GNU_GIMPLE
Add CTF command line options : -gtLEVEL
Setup for CTF generation and emission
CTF generation for a single
gcc/ChangeLog:
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h: New Prototype.
---
gcc/ChangeLog | 5 +
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
index 2df97f2..f3a64c
-gtLEVEL is used to request CTF debug information and also to specify how much
CTF debug information.
gcc/ChangeLog:
* common.opt: Add CTF debug info options.
* doc/invoke.texi: Document the CTF debug info options.
* flag-types.h (enum ctf_debug_info_levels): New enum.
[Changes from V3]
Added new testcases
- gcc.dg/debug/ctf/ctf-array-2.c
- gcc.dg/debug/ctf/ctf-complex-1.c
- gcc.dg/debug/ctf/ctf-enum-2.c
- gcc.dg/debug/ctf/ctf-func-index-1.c
- gcc.dg/debug/ctf/ctf-objt-index-1.c
- gcc.dg/debug/ctf/ctf-skip-types-1.c
gcc/testsuite/ChangeLog:
* gcc.
For each translation unit, a CTF container (ctf_container_t) is used to
keep the CTF debug info.
- ctfout.c hosts the compiler facing routines for CTF generation and emission.
- ctfcreate.c contains the CTF format specific CTF creation routines.
- ctfutils.c contains helper routines for CTF creati
\
+ ctfcreate.o \
symtab.o \
cgraph.o \
cgraphbuild.o \
Sorry for inconvenience,
Indu
On Wed, Jul 17, 2019 at 4:58 PM Indu Bhagat wrote:
>
> For each translation unit, a CTF container (ctf_container_t) is used to
> keep the CTF debug info.
>
> - ctfout.c hosts the
gcc/ChangeLog:
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h (lang_GNU_GIMPLE): New Prototype.
---
gcc/ChangeLog | 5 +
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
ind
-gtLEVEL is used to request CTF debug information and also to specify how much
CTF debug information.
gcc/ChangeLog:
* common.opt: Add CTF debug info options.
* doc/invoke.texi: Document the CTF debug info options.
* flag-types.h (enum ctf_debug_info_levels): New enum.
the CTF
section (.ctf) for a single compilation unit will be added.
Once CTF generation for a single compilation unit stabilizes, LTO and CTF
generation will be looked at.
Feedback and suggestions welcome.
Thanks
Indu Bhagat (3):
Add new function lang_GNU_GIMPLE
Add CTF command line options
Initialize CTF debug hooks when -gtLEVEL is specified. Import the CTF header
from binutils.
gcc/ChangeLog:
* Makefile.in: Add ctfout.* files to GTFILES.
* ctfout.c: New file.
* ctfout.h: Likewise.
* debug.h (ctf_debug_init): New function.
* gengtype.c (ope
On 10/30/24 11:31 AM, David Faust wrote:
gcc/
* doc/extend.texi (Common Variable Attributes): Document new
btf_decl_tag attribute.
(Common Type Attributes): Document new btf_type_tag attribute.
---
gcc/doc/extend.texi | 68 +
On 10/30/24 11:31 AM, David Faust wrote:
Support the btf_decl_tag and btf_type_tag attributes in BTF by creating
and emitting BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records,
respectively, for them.
Some care is required when -gprune-btf is in effect to avoid emitting
decl or type tags for decla
subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE)
instruction. It can be used to subtract an immediate value scaled by
the tag granule from the address in the source register.
gcc/ChangeLog:
* config/aarch64/aarch64.md (subg): New definition.
---
gcc/config/aarch64/aarch64.m
Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
instruction. It stores an allocation tag to two tag granules of memory.
TBD:
- Not too sure what is the best way to generate the st2g yet; A
subsequent patch will emit them in one of the target hooks.
- the current define_in
Add new command line option -fsanitize=memtag with the following
new params:
--param memtag-instrument-stack [0,1] (default 1) to use MTE
insns for enabling dynamic checking of stack variables.
--param memtag-instrument-alloca [0,1] (default 1) to use MTE
insns for enabling dynamic checking of st
Memory tagging is used for detecting memory safety bugs. On AArch64, the
memory tagging extension (MTE) helps in reducing the overheads of memory
tagging:
- CPU: MTE instructions for efficiently tagging and untagging memory.
- Memory: New memory type, Normal Tagged Memory, added to the Arm
Ar
Check for SANITIZER_MEMTAG in the gate function for pass_asan gimple
pass; enable it.
TBD:
- This commit was initially carved out in order to ensure each patch
works in isolation. Need to revisit and double check this.
gcc/ChangeLog:
* asan.cc (memtag_sanitize_p): Fix definition.
Currently, the data type of sanitizer flags is unsigned int, with
SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual
enumerator for enum sanitize_code. Use 'unsigned HOST_WIDE_INT' data
type to allow for more distinct instrumentation modes be added when
needed.
FIXME:
1. Is using d_u
1 - 100 of 220 matches
Mail list logo
