, 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 neg-imm
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 de
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 ca
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 in
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
instructions
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/
* doc/i
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.
gcc
[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
- At
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 v4
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 t
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 changed,
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
> ind
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 fr
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.
* gcc.dg/debug/dwarf2/annota
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(+)
diff
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 deletion
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 re
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.
---
include
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, wh
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. How
[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 t
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, which
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 below
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
gc
[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 a
[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 D
[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 record
[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 feedb
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
>> unsupported
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' lin
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.
gc
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): Likewi
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 n
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 gen
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 (3)
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?
Th
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 may
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, &bitsize, &bitpos, &var_off, &mode, &unsignedp,
>>+&reversep, &volatilep);
>
>Since the information returned by the builtin is always constant
>(positi
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);
Wh
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, Guillermo
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.
gcc/ChangeL
[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 computa
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 index
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 enumerat
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 addin
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 stri
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.
* 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 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 (gen_decl_annotation_dies)
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_asm_typ
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 re
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 cha
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 types.
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 1
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
l
The series adds support for new attribues btf_type_tag and btf_decl_tag,
for recording 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 att
/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 explain
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): L
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: Likewi
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.
(g
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 re
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
btf_debuginfo_p
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.
gcc
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 cha
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 1
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, whic
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 to
[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 standar
[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:
* config/bpf/core
1 - 100 of 136 matches
Mail list logo
