Add a new target hook TARGET_MEMTAG_TAG_MEMORY to tag (and untag)
memory. The default implementation is empty.
Hardware-assisted sanitizers on architectures providing instructions to
tag/untag memory can then make use of this target hook. On AArch64,
e.g., the MEMTAG sanitizer will use this hook
MEMTAG sanitizer, which is based on the HWASAN sanitizer, will invoke
the target-specific hooks to create a random tag, add tag to memory
address, and finally tag and untag memory.
Implement the target hooks to emit MTE instructions if MEMTAG sanitizer
is in effect. Continue to use the default ta
Add basic tests for MEMTAG sanitizer. MEMTAG sanitizer uses target
hooks to emit AArch64 specific MTE instructions.
Add new target-specific tests.
The currently generated code has quite a few limitations:
1. For basic-1.c testcase, currently we generate:
subgx0, x0, #16, #0
nables.html
[4] "DWARF for the Arm® 64-bit Architecture (AArch64)"
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
[5] "MTE – discussion on Exception unwinding ABI"
https://discourse.llvm.org/t/mte-discussion-on-exception-unwinding-abi/55226RFC
Thanks,
I
Hi,
I need some feedback/discussion on GCC/Binutils command line options
around MTE
tagged stack usage. See "Proposed GCC/Binutils implementation for the user
space ABI for MTE stack" below in the email for the high-level design.
Thanks
Indu
-
MTE Background
---
On 11/13/24 3:02 PM, Richard Sandiford wrote:
Indu Bhagat writes:
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
On 10/30/24 11:31 AM, David Faust wrote:
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used t
On 2/6/25 11:54 AM, David Faust wrote:
gcc/
* doc/extend.texi (Common Variable Attributes): Document
btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 68 +
1 file cha
On 2/6/25 11:54 AM, David Faust wrote:
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in BTF as BTF_KIND_DECL_TAG and
BTF_KIND_TYPE_TAG records.
The new CTF kinds used to
On 2/6/25 11:54 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 declara
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
Using post-index stg is a faster way of memory tagging/untagging.
TBD:
- Currently generated by in the aarch64 backend. Not sure if this
is the right way to do it.
- Also not clear how to weave in the generation of stzg.
ChangeLog:
* gcc/config/aarch64/aarch64.md
---
[New in RF
)"
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst
[5] "MTE – discussion on Exception unwinding ABI"
https://discourse.llvm.org/t/mte-discussion-on-exception-unwinding-abi/55226RFC
Thanks,
Indu Bhagat (14):
opts: use unsigned HOST_WIDE_INT for sanitizer flags
Using post-index st2g is a faster way of memory tagging/untagging.
Because a post-index 'st2g tag, [addr], #32' is equivalent to:
stg tag, addr, #0
stg tag, addr, #16
add addr, addr, #32
TBD:
- Currently generated by in the aarch64 backend. Not sure if this is
the right way to do i
Add a new target hook TARGET_MEMTAG_TAG_MEMORY to tag (and untag)
memory. The default implementation is empty.
Hardware-assisted sanitizers on architectures providing instructions to
tag/untag memory can then make use of this target hook. On AArch64,
e.g., the MEMTAG sanitizer will use this hook
Add basic tests for MEMTAG sanitizer. MEMTAG sanitizer uses target
hooks to emit AArch64 specific MTE instructions.
Add new target-specific tests.
The currently generated code currently has the following known
limitations:
1. For basic-1.c testcase, currently we generate:
subgx0, x0
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
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
Add new command line option -fsanitize-memtag-mode with three possible
values:
- sync (default)
- async
- asymm
This allows the user to select the fault conveyance model when using MTE
instructions for their applications.
This option is not (sanity checked) processed in GCC at all currently.
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.
gcc/ChangeLog:
MEMTAG sanitizer, which is based on the HWASAN sanitizer, will invoke
the target-specific hooks to create a random tag, add tag to memory
address, and finally tag and untag memory.
Implement the target hooks to emit MTE instructions if MEMTAG sanitizer
is in effect. Continue to use the default ta
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.
Emit .cfi_mte_memtag_frame after .cfi_startproc for each function where
the stack memory uses MTE protection.
TBD:
- Need to double check if checking on frame_size is the right thing to
do. clang generates cfi_mte_tagged_frame directive irrespective of
whether the function ended up taggi
In context of stack tagging, the AArch64 Memtag ABI Extension to ELF
specifies the usage of two dynamic tags for the dynamic loader to do the
necessary tasks:
- If DT_AARCH64_MEMTAG_MODE is present, the dynamic loader should (in
a platform-specific specific way) enable MTE for the process.
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
On 4/11/25 11:30 AM, Indu Bhagat wrote:
Hi,
For MTE stack tagging support in the GNU toolchain, one of the key pieces is
the memtag sanitizer in GCC. The current series is V2 of the previously sent
RFC series https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668017.html.
This is now
On 4/15/25 9:21 AM, Richard Sandiford wrote:
Indu Bhagat writes:
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
On 4/15/25 8:35 AM, Richard Sandiford wrote:
Hi,
Indu Bhagat writes:
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
On 4/15/25 11:52 AM, Richard Sandiford wrote:
Indu Bhagat writes:
Using post-index st2g is a faster way of memory tagging/untagging.
Because a post-index 'st2g tag, [addr], #32' is equivalent to:
stg tag, addr, #0
stg tag, addr, #16
add addr, addr, #32
TBD:
-
On 4/22/25 11:00 AM, Indu Bhagat wrote:
On 4/15/25 8:35 AM, Richard Sandiford wrote:
Hi,
Indu Bhagat writes:
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
On 4/15/25 9:21 AM, Richard Sandiford wrote:
Indu Bhagat writes:
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
On 5/6/25 3:53 AM, Richard Sandiford wrote:
Indu Bhagat writes:
On 4/15/25 9:21 AM, Richard Sandiford wrote:
Indu Bhagat writes:
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
On 5/1/25 7:03 AM, Richard Sandiford wrote:
Indu Bhagat writes:
[...]
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ffde9df85fd3..de651183a703 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17079,6 +17079,14 @@ and @option{-fsanitize=kernel-hwaddress}.
To
On 5/1/25 12:01 PM, Richard Sandiford wrote:
Indu Bhagat writes:
In context of stack tagging, the AArch64 Memtag ABI Extension to ELF
specifies the usage of two dynamic tags for the dynamic loader to do the
necessary tasks:
- If DT_AARCH64_MEMTAG_MODE is present, the dynamic loader should
Fix PR web/114649
---
htdocs/readings.html | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 56398317..3b0556e6 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -598,6 +598,10 @@ names.
https://dwarfstd.org";>DWARF Workgro
On 5/1/25 11:48 AM, Richard Sandiford wrote:
Indu Bhagat writes:
MEMTAG sanitizer, which is based on the HWASAN sanitizer, will invoke
the target-specific hooks to create a random tag, add tag to memory
address, and finally tag and untag memory.
Implement the target hooks to emit MTE
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
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/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 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 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
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/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)
ok 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 ne
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
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
-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
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
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/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
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
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/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
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.
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
-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
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
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
tter 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
[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
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
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
-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.
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
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
wards keeping it that way when possible. So in this
API ctf_add_enum, how about just adding another function argument for
signedness and getting rid of the data structure ctf_enum_binfo_t
altogether. What do you think ?
Patch looks good to me otherwise.
Thanks
Indu
{
ctf_dtde
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
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 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 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
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
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
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
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
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
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
'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/10074
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
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
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
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
.
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
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
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
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
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/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
--
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
onal -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
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
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
ke 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
-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
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
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.rele
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
4.
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/d
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.
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
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
101 - 200 of 220 matches
Mail list logo
