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
On 8/7/24 10:19, Will Hawkins wrote:
> On Mon, Jul 29, 2024 at 2:14 PM David Faust wrote:
>>
>>
>> On 7/29/24 07:42, Will Hawkins wrote:
>>> If the user provides a kind value that is more than 5 bits, the
>>> BTF_KIND_INFO macro would emit incorrect value
On 7/29/24 07:42, Will Hawkins wrote:
> If the user provides a kind value that is more than 5 bits, the
> BTF_KIND_INFO macro would emit incorrect values for info (by clobbering
> values of the kind flag).
>
> Tested on x86_64-redhat-linux.
OK, thanks.
>
> include/ChangeLog:
>
> * btf.
On 7/15/24 08:33, Cupertino Miranda wrote:
> Both xchg and cmpxchg instructions, in the pseudo-C dialect, do not
> expect their memory address operand to be surrounded by parentheses.
> For example, it should be output as "w0 =cmpxchg32_32(r8+8,w0,w2)"
> instead of "w0 =cmpxchg32_32((r8+8),w0,w2)".
[This is a resend of a patch previously sent as:
PATCH v4 6/6 opts: allow any combination of DWARF,CTF,BTF
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654253.html]
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made i
I was not aware of the requirement to regenerate the opt urls files
when adding a new option until the autobuilder complained.
Regenerate common.opt.urls for the -gprune-btf option added in:
b8977d928a7a btf: add -gprune-btf option
Pushed as obvious.
gcc/
* common.opt.urls: Regenerate.
Ping.
archive: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654253.html
On 6/11/24 12:01, David Faust wrote:
> Previously it was not supported to generate both CTF and BTF debug info
> in the same compiler run, as both formats made incompatible changes to
> the same inte
it.
Thanks!
archive: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654252.html
On 6/11/24 12:01, David Faust wrote:
> This patch adds a new option, -gprune-btf, to control BTF debug info
> generation.
>
> As the name implies, this option enables a kind of "pruning" of
On 6/12/24 09:55, Jose E. Marchesi wrote:
>
> Hi Faust.
> Thanks for the patch.
> Please see a question below.
>
>> This patch enables -gprune-btf by default in the BPF backend when
>> generating BTF information, and fixes BPF CO-RE generation when using
>> -gprune-btf.
>>
>> When generating B
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patches, in particular the
guarantee that CTF will always be fully emitted befor
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory repr
This patch adds a new option, -gprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
dire
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type I
This patch enables -gprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-gprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
represen
generating both CTF and BTF in the same compiler run,
allowing for any combinaion of -gdwarf, -gctf and -gbtf.
Tested on x86_64-linux-gnu, and on x86_64-linux-gnu host for
bpf-unknown-none target.
Also tested by compiling and runninng Linux kernel BPF selftests.
No known regressions.
David Faust
On 5/31/24 00:07, Richard Biener wrote:
> On Thu, May 30, 2024 at 11:34 PM David Faust wrote:
>>
>> This patch adds a new option, -fprune-btf, to control BTF debug info
>> generation.
>
> Can you name it -gprune-btf instead?
Yes, sure.
I think I followed -felimin
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type I
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patches, in particular the
guarantee that CTF will always be fully emitted befor
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
dire
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory repr
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
represen
and on x86_64-linux-gnu host for
bpf-unknown-none target.
Also tested by compiling and runninng Linux kernel BPF selftests.
No known regressions.
David Faust (6):
ctf, btf: restructure CTF/BTF emission
ctf: use pointers instead of IDs internally
btf: refactor and simplify implementation
On 5/3/24 2:02 PM, Indu Bhagat wrote:
> On 5/2/24 10:11, David Faust wrote:
>> This commit makes some structural changes to the CTF/BTF debug info
>> emission. In particular:
>>
>> a) CTF is new always fully generated and emitted before any
>> BTF-relate
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type I
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
dire
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patch, in particular the
guarantee that CTF will always be fully emitted before
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory repr
makes BTF pruning work with BPF CO-RE, and enables the pruning
by default in the BPF backend.
Tested on x86_64-linux-gnu, and on x86_64-linux-gnu host for
bpf-unknown-none target.
Also heavily tested with Linux kernel BPF selftests.
No known regressions.
David Faust (6):
ctf, btf: restructu
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
represen
On 5/1/24 12:15, David Faust wrote:
> This patch replaces all inter-type references in the ctfc internal data
> structures with pointers, rather than the references-by-ID which were
> used previously.
>
> A couple of small updates in the BPF backend are included to make it
> c
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type I
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory repr
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
dire
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
represen
rmation by a factor of 10.
Patch 6 makes BTF pruning work with BPF CO-RE, and enables the pruning
by default in the BPF backend.
Tested on x86_64-linux-gnu, and on x86_64-linux-gnu host for
bpf-unknown-none target.
Also heavily tested with Linux kernel BPF selftests.
No known regressions.
Davi
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patch, in particular the
guarantee that CTF will always be fully emitted before
BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
gcc/
* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.
gcc/testsuite/
* gcc.target/bpf/bpf-deb
Compiling a BPF program with CO-RE relocations (and BTF) while also
passing -gtoggle led to an inconsistent state where CO-RE support was
enabled but BTF would not be generated, and this was not caught by the
existing option parsing. This led to an ICE when generating the CO-RE
relocation info, si
Hi Cupertino,
On 4/18/24 13:58, Cupertino Miranda wrote:
> Hi David, everyone,
>
> Following Davids last review I decided to properly detect error cases,
> as suggested.
> The error however should be reported earlier in compilation in
> pack_enum_valud function, where all the errors are reported.
On 4/17/24 11:44, Cupertino Miranda wrote:
> The BPF backend was allocating an unnecessarily large string when
> constructing CO-RE relocations for enum types.
>
> gcc/ChangeLog:
> * config/bpf/core-builtins.cc (process_enum_value): Correct
> string allocation.
> ---
> gcc/config/b
This patch fixes a small error that could occur in the debug comment
when emitting a type reference with btf_asm_type_ref.
While working on a previous patch, I noticed the following in the asm
output for the test btf-bitfields-4.c:
...
.long 0x39# MEMBER 'c' idx=3
.l
[Changes from v1: use btf_dmd_representable_bitfield_p in
btf_asm_sou_member, instead of a slightly incorrect equivalent check.]
This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF. It is undefined what shou
1 - 100 of 286 matches
Mail list logo
