[was: ctf: use HOST_WIDE_INT for type bit sizes
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693262.html
Changed from previous:
- Fix similar truncation in member offset translation
- Restrict test to 64-bit targets ]
DWARF to CTF translation for type bit sizes was using uint32_t, a
Similar to the existing ptr32plus, add a proc returning whether the
target uses 64-bit or larger pointers. It can be useful immediately in
the CTF testsuite, and likely elsewhere.
Tested on x86_64-pc-linux-gnu and with cross for arm-eabi cortex-m3
in the CTF testsuite.
gcc/testsuite/
*
On 8/26/25 11:54, H.J. Lu wrote:
> On Mon, Aug 25, 2025 at 12:11 PM David Faust wrote:
>>
>>
>>
>> On 8/25/25 10:33, Indu Bhagat wrote:
>>> On 8/25/25 8:08 AM, David Faust wrote:
>>>>
>>>>
>>>> On 8/22/25 23:49, Indu Bh
The test fails to compile on 32-bit targets because the arrays are too
large. Restrict to targets where the array index type is 64-bits.
Also note the relevant PR in the test comment.
Tested on x86_64-pc-linux-gnu host and arm-eabi cross target.
Pushed as obvious.
PR debug/121411
gcc/te
When translating type bit sizes from DWARF, ctf_die_bitsize was
using uint32_t. For extremely large struct types, the bit size may be
larger than 32-bits and hence truncated, which caused incorrect encoding
for these huge structs rather than properly using CTF's large type size
encoding. Switchin
On 8/25/25 10:33, Indu Bhagat wrote:
> On 8/25/25 8:08 AM, David Faust wrote:
>>
>>
>> On 8/22/25 23:49, Indu Bhagat wrote:
>>> On 8/6/25 9:26 AM, David Faust wrote:
>>>> CTF array encoding uses uint32 for number of elements. This means there
>>&
On 8/22/25 23:49, Indu Bhagat wrote:
> On 8/6/25 9:26 AM, David Faust wrote:
>> CTF array encoding uses uint32 for number of elements. This means there
>> is a hard upper limit on array types which the format can represent.
>>
>
> Hi David,
>
> Thanks
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 declarations or types which have been pruned and
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
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 represent these annotations, CTF_K_DECL_T
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
27;rcu_s' type_id=5
'ptr' type_id=6
[5] PTR '(anon)' type_id=9
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_thing' type_id=4 linkage=global
[9] TYPE_TAG 'rcu' type_id=1
[10] TYPE_TAG &
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them. These attributes may be
used to annotate types or declarations respectively with arbitrary
strings, which will be recorded in DWARF and/or BTF information.
Both attributes accept exactly one
Hi Joseph,
On 8/20/25 15:49, Joseph Myers wrote:
> On Tue, 12 Aug 2025, David Faust wrote:
>
>> + if (TREE_CODE (*node) == FUNCTION_TYPE || TREE_CODE (*node) ==
>> METHOD_TYPE)
>> +{
>> + /* Treat btf_type_tag applied to a function type as applying to th
Ping.
Note: this patch doesn't fully resolve the PR (see discussion there)
but it does fix one existing truncation bug.
Thanks!
On 8/6/25 09:26, David Faust wrote:
> CTF array encoding uses uint32 for number of elements. This means there
> is a hard upper limit on array types which
Ping for v8.
archive link: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692443.html
Thanks!
On 8/12/25 15:32, David Faust wrote:
> [v7: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692127.html
> Review Status:
> - Patch 2,3 have been OK'd in v6 and are unchan
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 declarations or types which have been pruned and
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
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 represent these annotations, CTF_K_DECL_T
type_id=9
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_thing' type_id=4 linkage=global
[9] TYPE_TAG 'rcu' type_id=1
[10] TYPE_TAG 'foo' type_id=0
Note how the TYPE_TAG are injected into the type cha
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them. These attributes may be
used to annotate types or declarations respectively with arbitrary
strings, which will be recorded in DWARF and/or BTF information.
Both attributes accept exactly one
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 represent these annotations, CTF_K_DECL_T
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
[3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[4] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2
'rcu_s' type_id=5
'ptr' type_id=6
[5] PTR '(anon)' type_id=9
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_th
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
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 declarations or types which have been pruned and
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_decl_tag_attribute): New handler for btf_decl_tag.
On 8/6/25 13:22, Joseph Myers wrote:
> On Wed, 6 Aug 2025, David Faust wrote:
>
>> So IMO the best option will be to reject wide strings in the attribute
>> handler. (The alternative, I guess, is to ensure the argument is
>> always exported to UTF-8 before being writt
On 8/4/25 13:17, Joseph Myers wrote:
> On Mon, 4 Aug 2025, David Faust wrote:
>
>> Hi Joseph,
>>
>> Could you please take a look at the front-end portion of this
>> series when you have a moment?
>>
>> New attributes/handlers - Patch 1:
>> htt
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the format can represent.
GCC internally was also using a uint32_t for this, which would overflow
when translating from DWARF for arrays with more with more than
UINT32_MAX elements.
,
David
On 7/21/25 16:00, David Faust wrote:
> [v5: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689539.html
> Changes from v5:
> Patch 1 (C attribs):
> - Change btf_type_tag attribute handler to treat btf_type_tag applied to a
>function_type node as applying to
On 8/2/25 08:10, Indu Bhagat wrote:
> On 7/21/25 4:00 PM, 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 i
Hi Piyush,
On 7/17/25 05:13, Piyush Raj wrote:
> This patch adds new DejaGnu target board for BPF that enables execution
> testing
> of BPF programs using the `bpf-vmtest-tool` script in the contrib directory.
Sorry for the delay. I am hoping Thomas or Jose can chime in who know a bit more
about
-July/690141.html
and the implementation is patch 2
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690144.html
Thanks,
David
On 7/21/25 16:00, David Faust wrote:
> [v5: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689539.html
> Changes from v5:
> Patch 1 (C attribs
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
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 represent these annotations, CTF_K_DECL_T
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 declarations or types which have been pruned and
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
ptr' type_id=6
[5] PTR '(anon)' type_id=9
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_thing' type_id=4 linkage=global
[9] TYPE_TAG 'rcu' type_id=1
[10] TYPE_TAG 'foo' type_id=0
Note how the
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_decl_tag_attribute): New handler for btf_decl_tag.
On 7/17/25 05:16, Richard Biener wrote:
> On Tue, Jul 15, 2025 at 12:03 AM David Faust wrote:
>>
>> The btf_decl_tag and btf_type_tag attributes provide a means to annotate
>> declarations and types respectively with arbitrary user provided
>> strings. These st
On 7/10/25 10:21, Piyush Raj wrote:
> Hi David,
>
> On 09/07/25 03:33, David Faust wrote:
>>> diff --git a/contrib/bpf-vmtest-tool/.gitignore
>>> b/contrib/bpf-vmtest-tool/.gitignore
>>> new file mode 100644
>>> index 000..723dfe1d0f4
&
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
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 declarations or types which have been pruned and
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
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 represent these annotations, CTF_K_DECL_T
'rcu_s' type_id=5
'ptr' type_id=6
[5] PTR '(anon)' type_id=9
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_thing' type_id=4 linkage=global
[9] TYPE_TAG 'rcu' type_id=1
[10] TY
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with attribute handlers for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_decl_tag_attribute): New handler for btf_decl_tag.
Hi Piyush,
On 7/3/25 06:32, Piyush Raj wrote:
> This patch adds the bpf-vmtest-tool subdirectory under contrib which tests
> BPF programs under a live kernel using a QEMU VM. It automatically
> builds the specified kernel version with eBPF support enabled
> and stores it under "~/.bpf-vmtest-tool
On 7/2/25 00:42, Richard Biener wrote:
> On Tue, Jun 10, 2025 at 11:40 PM David Faust wrote:
>>
>> Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
>> along with a simple shared handler for them.
>>
>> gcc/c-family/
>
On 7/2/25 00:35, Richard Biener wrote:
> On Tue, Jul 1, 2025 at 11:20 PM David Faust wrote:
>>
>>
>>
>> On 7/1/25 01:02, Richard Biener wrote:
>>> On Mon, Jun 30, 2025 at 9:12 PM David Faust wrote:
>>>>
>>>>
>>&
On 7/1/25 01:02, Richard Biener wrote:
> On Mon, Jun 30, 2025 at 9:12 PM David Faust wrote:
>>
>>
>>
>> On 6/30/25 06:11, Richard Biener wrote:
>>>> +static void
>>>> +gen_btf_decl_tag_dies (tree t, dw_die_ref target, dw_die_ref context_di
On 6/30/25 06:11, Richard Biener wrote:
>> +static void
>> +gen_btf_decl_tag_dies (tree t, dw_die_ref target, dw_die_ref context_die)
>> +{
>> + if (t == NULL_TREE || !DECL_P (t) || !target)
>> +return;
>> +
>> + tree attr = lookup_attribute ("btf_decl_tag", DECL_ATTRIBUTES (t));
>> + if
Ping for the series
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686373.html
Thanks
On 6/10/25 14:41, David Faust wrote:
> [v3: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html
> Changes v3->v4:
> - Only patch 2 (DWARF generation) is changed; update based
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 declarations or types which have been pruned and
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
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 represent these annotations, CTF_K_DECL_T
_id=9
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_thing' type_id=4 linkage=global
[9] TYPE_TAG 'rcu' type_id=1
[10] TYPE_TAG 'foo' type_id=0
Note how the TYPE_TAG are injected into the type chain between
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attrib
On 5/6/25 01:24, Richard Biener wrote:
> On Mon, May 5, 2025 at 10:40 PM David Faust wrote:
>>
>>
>>
>> On 5/2/25 01:26, Richard Biener wrote:
>>> On Wed, Apr 30, 2025 at 7:26 PM David Faust wrote:
>>>>
>>>> The btf_decl
On 5/2/25 01:26, Richard Biener wrote:
> On Wed, Apr 30, 2025 at 7:26 PM David Faust wrote:
>>
>> The btf_decl_tag and btf_type_tag attributes provide a means to annotate
>> declarations and types respectively with arbitrary user provided
>> strings. These st
gcc/
* doc/extend.texi (Common Function Attributes)
(Common Variable Attributes): Document btf_decl_tag attribute.
(Common Type Attributes): Document btf_type_tag attribute.
---
gcc/doc/extend.texi | 79 +
1 file changed, 79 inser
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 declarations or types which have been pruned and
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 represent these annotations, CTF_K_DECL_T
[6] PTR '(anon)' type_id=10
[7] VAR 'x' type_id=3, linkage=global
[8] FUNC 'do_thing' type_id=4 linkage=global
[9] TYPE_TAG 'rcu' type_id=1
[10] TYPE_TAG 'foo' type_id=0
Note how the TYPE_TAG are injected into the type chain between the
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23 ++
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attrib
Ping.
this patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675242.html
series: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html
On 2/6/25 11:54, David Faust wrote:
> Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
could take a look once again?
Thanks!
archive links
this patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675243.html
series: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html
On 2/6/25 11:54, David Faust wrote:
> The btf_decl_tag and btf_type_tag attribu
Ping.
On 2/20/25 14:24, David Faust wrote:
>
> Gentle ping for this series.
> https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html
>
> On 2/6/25 11:54, David Faust wrote:
>> [v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666911.html
>> C
On 2/24/25 11:04, Indu Bhagat wrote:
> 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
On 2/24/25 11:03, Indu Bhagat wrote:
> 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 i
Gentle ping for this series.
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html
On 2/6/25 11:54, David Faust wrote:
> [v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666911.html
> Changes from v1:
> - Fix a bug in v1 related to generating DWARF for
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 declarations or types which have been pruned and
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 represent these annotations, CTF_K_DECL_T
f type tags which do not allow it to be
shared. The DIE for "rcu", however, is shared between uses.
And BTF information:
[1] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2
'rcu_s' type_id=2
'ptr' type_id=6
[2] TYPE_TAG 'rcu' type_id=3
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
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 changed, 68 insertions(+)
diff --git a/gcc/do
Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag"
along with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attrib
The BPF-specific .BTF.ext section is always generated for BPF programs
if -gbtf is specified, and generating it requires BTF information and
assumes that the BTF info has already been generated.
Compiling non-C languages to BPF is not supported, nor is generating
CTF/BTF for non-C. But, compiling
These maps will always be non-null in btf_finalize under normal
circumstances, but be safe and verify that before trying to empty them.
Tested on x86_64-linux-gnu and x86_64-linux-gnu host for bpf-unknown-none
target. Pushed as obvious.
gcc/
* btfout.cc (btf_finalize): Check that hash map
The btf_decl_tag and btf_type_tag attributes provide a means to annotate
declarations and types respectively with arbitrary user provided
strings. These strings are recorded in debug information for
post-compilation uses, and despite the name they are meant to be
recorded in DWARF as well as BTF.
[4] STRUCT 'S' size=4 vlen=1
...
[6] TYPE_TAG 'foo' type_id=7
[7] PTR '(anon)' type_id=0
[8] TYPE_TAG 'foo' type_id=9
[9] TYPE_TAG 'rcu' type_id=10
[10] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[11] VAR &#x
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 declarations or types which have been pruned and
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 represent these annotations, CTF_K_DECL_T
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 +
1 file changed, 68 insertions(+)
diff --git
Add two new c-family attributes, "btf_decl_tag" and "btf_type_tag" along
with a simple shared handler for them.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag and
btf_type_tag attributes.
(handle_btf_tag_attribute): New handler for both new attri
On 10/14/24 11:04, Cupertino Miranda wrote:
> Hi everyone,
>
> Here is the v2 for the patch in this thread:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665378.html
> Please noticed that commit message was adapted to new content.
>
> Regards,
> Cupertino
Hi Cupertino,
Thanks for
On 9/27/24 09:49, Cupertino Miranda wrote:
> CO-RE accesses with non pointer struct variables will also generate a
> "0" string access within the CO-RE relocation.
> The first index within the access string, has sort of a different
> meaning then the remaining of the indexes.
> For i0:i1:...:in
On 9/27/24 09:49, Cupertino Miranda wrote:
> When traversing gimple to introduce CO-RE relocation entries to
> expressions that are accesses to attributed perserve_access_index types,
> the access is likely to be split in multiple gimple statments.
> In order to keep doing the proper CO-RE conve
On 9/27/24 09:49, Cupertino Miranda wrote:
> Based on observation within bpf-next selftests and comparisson of GCC
> and clang compiled code, the BPF loader expects all CO-RE relocations to
> point to BTF non const type nodes.
> ---
> gcc/btfout.cc | 2 +-
> gcc
1 - 100 of 331 matches
Mail list logo
