, David Faust via Gcc-patches wrote:
> Hello,
>
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported in clang, and is used by various
> components of the BPF ecosystem.
>
> The purpose of the attribute is
The BPF virtual machine does not support neg nor neg32 instructions with
an immediate.
The erroneous instructions were removed from binutils:
https://sourceware.org/pipermail/binutils/2023-August/129135.html
Change the define_insn so that an immediate cannot be accepted.
>From testing, a
This define_insn is never used, since a sign-extend to the same mode is
just a move, so delete it.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
gcc/
* config/bpf/bpf.md (extendsisi2): Delete useless define_insn.
---
gcc/config/bpf/bpf.md | 7 ---
1 file changed, 7
In the BPF pseudo-c assembly dialect, registers treated as 32-bits
rather than the full 64 in various instructions ought to be printed as
"wN" rather than "rN". But bpf_print_register () was only doing this
for specifically SImode registers, meaning smaller modes were printed
incorrectly.
This
Ping for this series.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html
Thanks
On 7/11/23 14:57, David Faust via Gcc-patches wrote:
> Hello,
>
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported
ChangeLog:
* MAINTAINERS: Add the BPF port to my reviewer listing.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6cac5ac6671..1e54844c905 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -273,7 +273,7 @@ arc port
On 7/27/23 15:27, Jose E. Marchesi wrote:
>
> Hi David.
> Thanks for the patch.
>
>> BPF ISA V4 introduces sign-extending move and load operations. This
>> patch makes the BPF backend generate those instructions, when enabled
>> and useful.
>>
>> A new option, -m[no-]smov gates generation of
BPF ISA V4 introduces sign-extending move and load operations. This
patch makes the BPF backend generate those instructions, when enabled
and useful.
A new option, -m[no-]smov gates generation of these instructions, and is
enabled by default for -mcpu=v4 and above. Tests for the new
This patch makes some minor cleanups to eBPF options documented in
invoke.texi:
- Delete some vestigal docs for removed -mkernel option
- Add -mbswap and -msdiv to the option summary
- Note the negative versions of several options
- Note that -mcpu=v4 also enables -msdiv.
gcc/
*
The pseudo-C output templates for these instructions were incorrectly
using operand 1 rather than operand 2 on the RHS, which led to some
very incorrect assembly generation with -masm=pseudoc.
Tested on bpf-unknown-none.
OK?
gcc/
* config/bpf/bpf.md (add3): Use %w2 instead of %w1
[Changes from v1: save calls to fprintf]
Unfortunately, the pseudo-C dialect syntax used for some of the v3
atomic instructions clashes with unconditionally printing the
surrounding parentheses in bpf_print_operand_address.
Instead, place the parentheses in the output templates where needed.
[Changes from v1: fix merge issue in invoke.texi]
This patch adds support for the general atomic operations introduced in
eBPF v3. In addition to the existing atomic add instruction, this adds:
- Atomic and, or, xor
- Fetching versions of these operations (including add)
- Atomic exchange
-
On 7/25/23 15:14, Jose E. Marchesi wrote:
>
> Hi David.
>
>> Unfortunately, the pseudo-C dialect syntax used for some of the v3
>> atomic instructions clashes with unconditionally printing the
>> surrounding parentheses in bpf_print_operand_address.
>>
>> Instead, place the parentheses in the
On 7/25/23 15:18, Jose E. Marchesi wrote:
>
> Hi David.
>
>> +<<< HEAD
>
> There is a merge problem there.
Ugh, I swear I've fixed this twice now. Yet it keeps cropping up.
Sorry. v2 shortly.
>
>> @opindex mbswap
>> @item -mbswap
>> Enable byte swap instructions. Enabled for CPU
This patch adds support for the general atomic operations introduced in
eBPF v3. In addition to the existing atomic add instruction, this adds:
- Atomic and, or, xor
- Fetching versions of these operations (including add)
- Atomic exchange
- Atomic compare-and-exchange
To control emission of
Unfortunately, the pseudo-C dialect syntax used for some of the v3
atomic instructions clashes with unconditionally printing the
surrounding parentheses in bpf_print_operand_address.
Instead, place the parentheses in the output templates where needed.
Tested in bpf-unknown-none.
OK?
gcc/
The define_insn "nop" was missing a template for the pseudo-c dialect,
so the normal syntax was unconditionally emitted.
Tested on bpf-unknown-none, committed as obvious.
gcc/
* config/bpf/bpf.md (nop): Add pseudo-c asm dialect template.
---
gcc/config/bpf/bpf.md | 2 +-
1 file
Gentle ping.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html
On 7/11/23 14:57, David Faust via Gcc-patches wrote:
> Hello,
>
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported in clang,
Hi Cupertino,
On 7/21/23 09:43, Cupertino Miranda wrote:
> gcc/ChangeLog:
>
> * config/bpf/bpf.md: fixed template for neg instruction.
> ---
> gcc/config/bpf/bpf.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/bpf/bpf.md b/gcc/config/bpf/bpf.md
>
mponent in the kernel (pahole).]
>>>
>>> Hi Richard.
>>>
>>>> On Tue, Jul 11, 2023 at 11:58 PM David Faust via Gcc-patches
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> This series adds suppor
This patch updates btfout.cc to be aware of BTF_KIND_DECL_TAG types and
output them appropriately.
gcc/
* btfout.cc (funcs_map): New hash map.
(btf_emit_preprocess): ... Initialize it here...
(btf_collect_datasec): ... Populate it here...
(btf_finalize): ... And
Add the "btf_decl_tag" attribute to the attribute table, along with
a simple handler for it.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag.
(handle_btf_decl_tag_attribute): Handle new attribute.
---
gcc/c-family/c-attribs.cc | 23
This patch adds tests for the btf_decl_tag attribute, in both DWARF
and BTF.
gcc/testsuite/
* gcc.dg/debug/btf/btf-decltag-func.c: New test.
* gcc.dg/debug/btf/btf-decltag-sou.c: New test.
* gcc.dg/debug/btf/btf-decltag-var.c: New test.
*
This patch makes the DWARF-to-CTF conversion process aware of the new
DW_TAG_GNU_annotation DIEs. The DIEs are converted to CTF_K_DECL_TAG
types and added to the compilation unit CTF container to be translated
to BTF and output.
gcc/
* dwarf2ctf.cc (handle_btf_tags): New function.
Add documentation for the btf_decl_tag attribute.
gcc/
* doc/extend.texi (Common Function Attributes): Document btf_decl_tag.
(Common Variable Attributes): Likewise.
---
gcc/doc/extend.texi | 47 +
1 file changed, 47 insertions(+)
Expose get_die_parent () so it can be used outside of dwarf2out.cc
gcc/
* dwarf2out.cc (get_die_parent): Make non-static.
* dwarf2out.h (get_die_parent): Add extern declaration here.
---
gcc/dwarf2out.cc | 2 +-
gcc/dwarf2out.h | 1 +
2 files changed, 2 insertions(+), 1
The "btf_decl_tag" attribute is handled by constructing a
DW_TAG_GNU_annotation DIE for each occurrence to record the argument
string in debug information. The DIEs are children of the declarations
they annotate, with the following format:
DW_TAG_GNU_annotation
DW_AT_name "btf_decl_tag"
BTF generation currently relies on the internal CTF representation to
convert debug info from DWARF dies. This patch adds a new internal
header, "ctf-int.h", which defines CTF kinds to be used internally to
represent BTF tags which must pass through the CTF container. It also
adds a new type for
Add definitions for btf_decl_tag and the DW_TAG_GNU_annotation
DWARF extension.
include/
* btf.h (struct btf_type): Update comment.
(BTF_KIND_DECL_TAG): New define.
(struct btf_decl_tag): New.
* dwarf2.def (DW_TAG_GNU_annotation): New DW_TAG extension.
---
Hello,
This series adds support for a new attribute, "btf_decl_tag" in GCC.
The same attribute is already supported in clang, and is used by various
components of the BPF ecosystem.
The purpose of the attribute is to allow to associate (to "tag")
declarations with arbitrary string annotations,
Commit 7aae58b04b9 "btf: improve -dA comments for testsuite" broke
bootstrap on a number of architectures because it introduced some
new -Wformat errors.
Fix those errors by properly using PRIu64 and a small refactor to
the offending code.
Based on the suggested patch from Rainer Orth.
Committed
[Changes from v1:
- Fix typos.
- Split unrelated change into separate commit.
- Improve asm comment for enum constants, update btf-enum-1 test.
- Improve asm comment for DATASEC records, update btf-datasec-2 test.]
Many BTF type kinds refer to other types via index to the final types
list.
[Changes from v1: split this change into own commit.]
All BTF type records have a 4-byte field used to encode a size or link
to another type, depending on the type kind. But BTF_KIND_ARRAY and
BTF_KIND_FWD do not use this field at all, and should write zero.
GCC already correctly writes zero in
On 5/30/23 00:30, Indu Bhagat wrote:
> 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 s
Many BTF type kinds refer to other types via index to the final types
list. However, the order of the final types list is not guaranteed to
remain the same for the same source program between different runs of
the compiler, making it difficult to test inter-type references.
This patch updates the
In some cases where the target memory address for an ldx or stx
instruction could be reduced to a constant, GCC could emit a malformed
instruction like:
ldxdw %r0,0
Rather than the expected form:
ldxdw %rX, [%rY + OFFSET]
This is due to the constraint allowing a const_int operand,
Hi Jose,
As we discussed on IRC, since we don't currently define
TARGET_SUPPORTS_WIDE_INT it is safer to keep the handling for VOIDmode
CONST_DOUBLEs. My current understanding is that it may be needed if the
host is a 32-bit platform.
I also added a gcc_unreachable () as you pointed out. V2
The existing logic in bpf_print_operand was only correct for integral
CONST_DOUBLEs, and emitted garbage for floating point modes. Fix it so
floating point mode operands are correctly handled.
Tested on bpf-unknown-none, no known regressions.
OK to check-in?
Thanks.
PR target/108293
[Changes from v1:
- Add enum btf_func_linkage to include/btf.h and use it.
- Minor updates to comments based on review. ]
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
[Changes from v1: Minor updates to comments per review. ]
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
In addition, the internal
[Changes from v1:
- Add enum btf_var_linkage in include/btf.h and use that instead of
local #defines.
- Fix BTF generation for extern variable with both non-defining and
defining decls in the same CU. Add a test for this. ]
Add support for the 'extern' linkage value for BTF_KIND_VAR
[Changes from v1:
- Remove #defines for LINKAGE_* values, instead mirror enums from
linux/btf.h to include/btf.h and use those.
- Fix BTF generation for extern variable with both non-defining and
defining decls in the same CU. Add a test for this.
- Update several comments per review
On 12/8/22 23:34, Indu Bhagat wrote:
> Looks OK to me overall. Minor comments below.
>
> Thanks
>
> On 12/7/22 12:57, David Faust wrote:
>> The eBPF loader expects to find BTF_KIND_VAR records for references to
>> extern const void symbols. We were mistakenly identifing these as
>>
On 12/8/22 22:55, Indu Bhagat wrote:
> Hi David,
>
> On 12/7/22 12:57, David Faust wrote:
>> Add support for the 'extern' linkage value for BTF_KIND_VAR records,
>> which is used for variables declared as extern in the source file.
>>
>> PR target/106773
>>
>> gcc/
>>
>> * btfout.cc
On 12/8/22 23:36, Indu Bhagat wrote:
> On 12/7/22 12:57, David Faust wrote:
>> The eBPF loader expects to find entries for functions declared as extern
>> in the corresponding BTF_KIND_DATASEC record, but we were not generating
>> these entries.
>>
>> This patch adds support for the 'extern'
The eBPF architecture provides 'end[be,le]' instructions for endianness
swapping. Add a define_insn for bswap2 to use them instaed of
falling back on a libcall.
Tested on bpf-unknown-none, no known regressions.
OK to commit?
Thanks
gcc/
* config/bpf/bpf.md (bswap2): New define_insn.
Add support for the 'extern' linkage value for BTF_KIND_VAR records,
which is used for variables declared as extern in the source file.
PR target/106773
gcc/
* btfout.cc (BTF_LINKAGE_STATIC): New define.
(BTF_LINKAGE_GLOBAL): Likewise.
(BTF_LINKAGE_EXTERN):
The eBPF loader expects to find entries for functions declared as extern
in the corresponding BTF_KIND_DATASEC record, but we were not generating
these entries.
This patch adds support for the 'extern' linkage of function types in
BTF, and creates entries for for them BTF_KIND_DATASEC records as
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
In addition, the internal DWARF representation from which BTF is
produced does not
Hi,
This series fixes the issues reported in target/PR106773. I decided to
split it into three commits, as there are ultimately three distinct
issues and fixes. See each patch for details.
Tested on bpf-unknown-none and x86_64-linux-gnu, no known regressions.
OK to push?
Thanks.
David Faust
Fix a maybe-uninitialized warning introduced in commit:
068baae1864 bpf: add preserve_field_info builtin
Thanks to Jan-Benedict Glaw for pointing this out.
Tested on bpf-unknown-none, committed as obvious.
gcc/
* config/bpf/bpf.cc (bpf_expand_builtin): Avoid use of uninitialized
Change several places in the eBPF backend dealing with overloaded
built-in functions to consistently use the enum bpf_builtins type,
rather than variously using integer constants or booleans. The result is
eaiser to read and extend.
Tested on bpf-unknown-none, no known regressions.
OK to push?
Commit 068baae1864 "bpf: add preserve_field_info builtin" factored out
some repeated code to a new function maybe_make_core_relo (), but missed
using it in one place. Clean that up.
Regtested on bpf-unknown-none, pushed as obvious.
gcc/
* config/bpf/bpf.cc (handle_attr_preserve): Use
On 10/26/22 12:33, Jose E. Marchesi wrote:
>
> Hi David.
>
> Thanks for the updates.
> OK for master.
>
Pushed, thanks.
>> I'm not sure whether this behavior is a known limitation or an
>> oversight. In my opinion it makes more sense to error at compile time,
>> becuase even after the loader patches the return value it still will
>> not be correct for these cases.
>>
>> So for now I've set these cases to error out,
Hi Jose,
Thanks for your comments. I think I've addressed them all in the updated
patch below.
>>+ get_inner_reference (src, , , _off, , ,
>>+, );
>
>Since the information returned by the builtin is always constant
>(positions, sizes) I think you will want to adjust the code
Add BPF __builtin_preserve_field_info. This builtin is used to extract
information to facilitate struct and union relocations performed by the
BPF loader, especially for bitfields.
The builtin has the following signature:
unsigned int __builtin_preserve_field_info (EXPR, unsigned int KIND);
Hi Guillermo,
Thanks for the patch. Just a couple of small nits on the changelog
entries below but otherwise very nice, LGTM.
But, please wait a couple of days before pushing to give Indu time
to raise any objections about the changes in ctfc/dwarf2ctf.
Thanks!
David
On 8/29/22 14:11,
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
Tested on bpf-unknown-none and x86_64, no known regressions.
OK?
Thanks.
[changes from v1: simplify the new conditional logic as suggested.]
The old method for computing a member index for a CO-RE relocation
relied on a name comparison, which could SEGV if the member in question
is itself part of an anonymous inner struct or union.
This patch changes the index
On 8/29/22 12:57, Jose E. Marchesi wrote:
>
> Hi David.
>
>> The old method for computing a member index for a CO-RE relocation
>> relied on a name comparison, which could SEGV if the member in question
>> is itself part of an anonymous inner struct or union.
>>
>> This patch changes the
The old method for computing a member index for a CO-RE relocation
relied on a name comparison, which could SEGV if the member in question
is itself part of an anonymous inner struct or union.
This patch changes the index computation to not rely on a name, while
maintaining the ability to account
On 8/2/22 08:42, Jose E. Marchesi wrote:
>
>> On 7/26/22 14:58, Indu Bhagat wrote:
>>> 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
On 7/26/22 14:58, Indu Bhagat wrote:
> 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
On 7/12/22 08:13, 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
ChangeLog:
* MAINTAINERS: Add myself as reviewer for CTF and BTF.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7408396471f..1a37f4419b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -267,6 +267,7 @@ arc port
On 6/14/22 22:53, Yonghong Song wrote:
>
>
> On 6/7/22 2:43 PM, David Faust wrote:
>> Hello,
>>
>> This patch series adds support for:
>>
>> - Two new C-language-level attributes that allow to associate (to "annotate"
>> or
>>to "tag") particular declarations and types with arbitrary
gcc/
* doc/extend.texi (Common Function Attributes): Document
debug_annotate_decl attribute.
(Common Variable Attributes): Likewise.
(Common Type Attributes): Likewise. Also document
debug_annotate_type attribute.
---
gcc/doc/extend.texi | 106
This patch adds tests for debug annotations, in BTF and in DWARF.
gcc/testsuite/
* gcc.dg/debug/btf/btf-decltag-func.c: New test.
* gcc.dg/debug/btf/btf-decltag-sou.c: Likewise.
* gcc.dg/debug/btf/btf-decltag-typedef.c: Likewise.
*
This patch makes the DWARF-to-CTF conversion process aware of the new
DW_TAG_GNU annotation DIEs. The DIEs are converted to an internal-only
CTF representation as appropriate and added to the compilation unit CTF
container.
gcc/
* dwarf2ctf.cc (handle_debug_annotations): New function.
The "debug_annotate_decl" and "debug_annotate_type" attributes are
handled by constructing DW_TAG_GNU_annotation DIEs. These DIEs are
children of the declarations or types which they annotate, and convey
the information via a string constant.
gcc/
* dwarf2out.cc
This patch updates btfout.cc to be aware of debug annotations, convert
them to BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records, and output them
appropriately.
gcc/
* btfout.cc (get_btf_kind): Handle TYPE_TAG and DECL_TAG kinds.
(btf_calc_num_vbytes): Likewise.
BTF generation currently relies on the internal CTF representation to
convert debug info from DWARF dies. This patch adds a new internal
header, "ctf-int.h", which defines CTF kinds to be used internally to
represent BTF tags which must pass through the CTF container. It also
adds a new type for
This patch adds attribute handlers for two new attributes:
"debug_annotate_decl" and "debug_annotate_type". Both attributes accept
a single string argument, and are used to add arbitrary annotations to
debug information generated for the decls or types to which they apply.
gcc/c-family/
include/
* btf.h: Add BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG defines. Update
comments.
(struct btf_decl_tag): New.
* dwarf2.def: Add new DWARF extension DW_TAG_GNU_annotation.
---
include/btf.h | 17 +++--
include/dwarf2.def | 4
2 files
Hello,
This patch series adds support for:
- Two new C-language-level attributes that allow to associate (to "annotate" or
to "tag") particular declarations and types with arbitrary strings. As
explained below, this is intended to be used to, for example, characterize
certain pointer
gcc/
* dwarf2out.cc (dw_get_die_parent): New function.
* dwarf2out.h (dw_get_die_parent): Declare it here.
---
gcc/dwarf2out.cc | 8
gcc/dwarf2out.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 29f32ec6939..9c61026bb34
0/22 8:43 PM, Yonghong Song wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/6/22 2:18 PM, David Faust wrote:
>>>>>>>>>>>>
>>>>>>>>>>>
;>>>>>>
>>>>>>>> On 5/10/22 8:43 PM, Yonghong Song wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/6/22 2:18 PM, David Faust wrote:
>>>>>>>>>>
>>>>>>>>>>
>>
t;>>>>>>
>>>>>>>> On 5/5/22 16:00, Yonghong Song wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/4/22 10:03 AM, David Faust wrote:
>>>>>>>>>>
>>&g
t;
>>>>> On 5/6/22 2:18 PM, David Faust wrote:
>>>>>>
>>>>>>
>>>>>> On 5/5/22 16:00, Yonghong Song wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 5/4/22 10:03 AM, David Faust
On 5/10/22 22:05, Yonghong Song wrote:
On 5/10/22 8:43 PM, Yonghong Song wrote:
On 5/6/22 2:18 PM, David Faust wrote:
On 5/5/22 16:00, Yonghong Song wrote:
On 5/4/22 10:03 AM, David Faust wrote:
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc
On 5/5/22 16:00, Yonghong Song wrote:
On 5/4/22 10:03 AM, David Faust wrote:
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
#define __typetag1 __attribute__((btf_type_tag("tag1")))
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
#define __typetag1 __attribute__((btf_type_tag("tag1")))
#define __typetag2 __attribute__((btf_type_tag("tag2")))
#define __ty
ding arbitrary string tags in DWARF and BTF debug info. The
feature is to support kernel use cases.
Thanks,
David
On 4/1/22 12:42, David Faust via Gcc-patches wrote:
Hello,
This patch series is a first attempt at adding support for:
- Two new C-language-level attributes that allow to asso
/22 12:42, David Faust via Gcc-patches wrote:
Hello,
This patch series is a first attempt at adding support for:
- Two new C-language-level attributes that allow to associate (to "tag")
particular declarations and types with arbitrary strings. As explained below,
this is intended
On 4/4/22 15:13, Yonghong Song wrote:
On 4/1/22 12:42 PM, David Faust wrote:
Hello,
This patch series is a first attempt at adding support for:
- Two new C-language-level attributes that allow to associate (to "tag")
particular declarations and types with arbitrary strings. As
This patch updates btfout.cc to be aware of the DECL_TAG and TYPE_TAG
kinds and output them appropriately.
gcc/
* btfout.cc (get_btf_kind): Handle TYPE_TAG and DECL_TAG kinds.
(btf_calc_num_vbytes): Likewise.
(btf_asm_type): Likewise.
(output_asm_btf_vlen_bytes):
This commit adds tests for the tags, in BTF and in DWARF.
gcc/teststuite/
* gcc.dg/debug/btf/btf-decltag-func.c: New test.
* gcc.dg/debug/btf/btf-decltag-sou.c: Likewise.
* gcc.dg/debug/btf/btf-decltag-typedef.c: Likewise.
* gcc.dg/debug/btf/btf-typetag-1.c:
This patch makes the DWARF-to-CTF conversion process aware of the new
DW_TAG_GNU_annotation DIEs. The DIEs are converted to CTF_K_DECL_TAG or
CTF_K_TYPE_TAG types as approprate and added to the compilation unit CTF
container.
gcc/
* dwarf2ctf.cc (handle_btf_tags): New function.
BTF generation currently relies on the internal CTF representation to
convert debug info from DWARF dies. This patch adds a new internal
header, "ctf-int.h", which defines CTF kinds to be used internally to
represent BTF tags which must pass through the CTF container. It also
adds a new type for
The "btf_decl_tag" and "btf_type_tag" attributes are handled by
constructing DW_TAG_LLVM_annotation DIEs. The DIEs are children of the
declarations or types which they annotate, and convey the annotation via
a string constant.
Currently, all generation of these DIEs is gated behind
This patch adds attribute handlers in GCC for two attributes already
supported in LLVM: "btf_decl_tag" and "btf_type_tag". Both attributes
accept a single string constant argument, and are used to add arbitrary
annotations to debug information generated for the types/decls to which
they apply.
include/
* btf.h: Add BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG defines. Update
comments.
(struct btf_decl_tag): New.
* dwarf2.def: Add new DWARF extension DW_TAG_GNU_annotation.
---
include/btf.h | 17 +++--
include/dwarf2.def | 4
2 files
gcc/
* dwarf2out.cc (dw_get_die_parent): New function.
* dwarf2out.h (dw_get_die_parent): Declare it here.
---
gcc/dwarf2out.cc | 8
gcc/dwarf2out.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5681b01749a..35322fb5f6e
Hello,
This patch series is a first attempt at adding support for:
- Two new C-language-level attributes that allow to associate (to "tag")
particular declarations and types with arbitrary strings. As explained below,
this is intended to be used to, for example, characterize certain pointer
On 1/18/22 13:18, Jose E. Marchesi wrote:
Hi David.
[Changed from v1: Adjust to account for file renaming so patch applies.]
BPF CO-RE relocations contain offsets to strings buffered in the BTF
string table. These BTF-specific strings are stored in memory in the
CTF auxilliary strtab,
On 1/18/22 13:17, Jose E. Marchesi wrote:
Hi David.
[Changed from v1: Adjust to account for file renaming so patch applies.]
The CO-RE relocation record size should be written only once in the
.BTF.ext section, not once for each section with relocations.
Tested for bpf-unknown-none. OK
[Changed from v1: Adjust to account for file renaming so patch applies.]
BPF CO-RE relocations contain offsets to strings buffered in the BTF
string table. These BTF-specific strings are stored in memory in the
CTF auxilliary strtab, which at output time is concatenated onto the end
of the
[Changed from v1: Adjust to account for file renaming so patch applies.]
The CO-RE relocation record size should be written only once in the
.BTF.ext section, not once for each section with relocations.
Tested for bpf-unknown-none. OK to install?
Thanks.
gcc/ChangeLog:
*
1 - 100 of 136 matches
Mail list logo
