Re: [PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

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

[PATCH v4 6/6] opts: allow any combination of DWARF, CTF, BTF

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

[PATCH v4 2/6] ctf: use pointers instead of IDs internally

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

[PATCH v4 4/6] btf: add -gprune-btf option

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

[PATCH v4 3/6] btf: refactor and simplify implementation

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

[PATCH v4 5/6] bpf,btf: enable BTF pruning by default for BPF

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

[PATCH v4 1/6] ctf, btf: restructure CTF/BTF emission

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

[PATCH v4 0/6] btf: refactor and add pruning option

ating 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 (6):

Re: [PATCH v3 4/6] btf: add -fprune-btf option

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 -fe

[PATCH v3 3/6] btf: refactor and simplify implementation

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

[PATCH v3 5/6] bpf,btf: enable BTF pruning by default for BPF

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

[PATCH v3 6/6] opts: allow any combination of DWARF, CTF, BTF

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

[PATCH v3 4/6] btf: add -fprune-btf option

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

[PATCH v3 2/6] ctf: use pointers instead of IDs internally

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

[PATCH v3 1/6] ctf, btf: restructure CTF/BTF emission

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

[PATCH v3 0/6] btf: refactor and add pruning option

6_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 btf: add -

Re: [PATCH v2 1/6] ctf, btf: restructure CTF/BTF emission

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

[PATCH v2 6/6] bpf,btf: enable BTF pruning by default for BPF

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

[PATCH v2 4/6] btf: refactor and simplify implementation

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

[PATCH v2 5/6] btf: add -fprune-btf option

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

[PATCH v2 2/6] opts: allow any combination of DWARF, CTF, BTF

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

[PATCH v2 3/6] ctf: use pointers instead of IDs internally

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

[PATCH v2 0/6] btf: refactor and add pruning option

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

[PATCH v2 1/6] ctf, btf: restructure CTF/BTF emission

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

Re: [PATCH 3/6] ctf: use pointers instead of IDs internally

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

[PATCH 4/6] btf: refactor and simplify implementation

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

[PATCH 3/6] ctf: use pointers instead of IDs internally

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

[PATCH 5/6] btf: add -fprune-btf option

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

[PATCH 6/6] bpf,btf: enable BTF pruning by default for BPF

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

[PATCH 1/6] ctf, btf: restructure CTF/BTF emission

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

[PATCH 0/6] btf: refactor and add pruning option

nformation 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

[PATCH 2/6] opts: allow any combination of DWARF, CTF, BTF

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

[gcc r14-10135] bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG

https://gcc.gnu.org/g:1604f7cebc49220e47d584615bcd91b1fdc1267f commit r14-10135-g1604f7cebc49220e47d584615bcd91b1fdc1267f Author: David Faust Date: Wed Apr 24 15:01:02 2024 -0700 bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG BTF is the standard debug info used with BPF programs

[gcc r14-10131] bpf: avoid issues with CO-RE and -gtoggle

https://gcc.gnu.org/g:f175622d25e4146bb7450430831ec48615e6e4cb commit r14-10131-gf175622d25e4146bb7450430831ec48615e6e4cb Author: David Faust Date: Thu Apr 25 09:31:14 2024 -0700 bpf: avoid issues with CO-RE and -gtoggle Compiling a BPF program with CO-RE relocations (and BTF

[PATCH] bpf: set PREFERRED_DEBUGGING_TYPE to BTF_DEBUG

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/ *

[PATCH] bpf: avoid issues with CO-RE and -gtoggle

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,

Re: [PATCH v3] bpf: remove huge memory waste with string allocation.

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

Re: [PATCH v2] bpf: remove huge memory waste with string allocation.

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 r14-9928] btf: fix a possibly misleading asm debug comment

https://gcc.gnu.org/g:9b8bc02037eeaf4d6365010bb0533385deb4a90d commit r14-9928-g9b8bc02037eeaf4d6365010bb0533385deb4a90d Author: David Faust Date: Thu Apr 11 12:52:36 2024 -0700 btf: fix a possibly misleading asm debug comment This patch fixes a small error that could occur

[gcc r14-9927] btf: emit non-representable bitfield as void

https://gcc.gnu.org/g:f079d69d7b1338522562516537d96e9e1285c95e commit r14-9927-gf079d69d7b1338522562516537d96e9e1285c95e Author: David Faust Date: Thu Apr 11 11:18:55 2024 -0700 btf: emit non-representable bitfield as void This patch fixes an issue with mangled BTF that could

[PATCH] btf: fix a possibly misleading asm debug comment

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

[PATCH v2] btf: emit non-representable bitfield as void

[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

Re: [PATCH] btf: emit non-representable bitfield as void

On 4/11/24 13:40, Indu Bhagat wrote: > On 4/11/24 11:53, David Faust wrote: >> 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 should happen in s

[PATCH] btf: emit non-representable bitfield as void

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 should happen in such cases, but we can at least do something reasonable. Commit 936dd627cd9 "btf: do not skip members of data

Re: [PATCH 2/3] bpf: remove huge memory waste with string allocation.

Hi Cupertino, On 4/11/24 04:11, Cupertino Miranda wrote: > Code was allocating way too much space for the string. A little bit more description would not hurt. Perhaps you could say something like: "The BPF backend was allocating an unnecessarily large string when constructing CO-RE relocations

Re: [PATCH 2/2] btf: do not skip members of data type with type id BTF_VOID_TYPEID

Hi Indu, On 4/10/24 11:25, Indu Bhagat wrote: > Testing the previous fix in gen_ctf_sou_type () reveals an issue in BTF > generation, however: BTF emission was currently decrementing the vlen > (indicating the number of members) to skip members of type CTF_K_UNKNOWN > altogether, but still

Re: [PATCH 1/2] ctf: fix PR debug/112878

On 4/10/24 11:25, Indu Bhagat wrote: > PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in > a struct and -gctf1 > > The CTF generation in GCC does not have a mechanism to roll-back an > already added type. In this testcase presented in the PR, we hit a > representation

[gcc r14-9878] btf: improve btf-datasec-3.c test [PR114642]

https://gcc.gnu.org/g:639215c5eb6c56ba3830cd868d1d3ddd700b4c90 commit r14-9878-g639215c5eb6c56ba3830cd868d1d3ddd700b4c90 Author: David Faust Date: Mon Apr 8 13:33:48 2024 -0700 btf: improve btf-datasec-3.c test [PR114642] This test failed on powerpc --target_board=unix'{-m32

[gcc r14-9876] btf: emit symbol refs in DATASEC entries only for BPF [PR114608]

https://gcc.gnu.org/g:8075477f81ae8d0abf64b80dfbd179151f91b417 commit r14-9876-g8075477f81ae8d0abf64b80dfbd179151f91b417 Author: David Faust Date: Mon Apr 8 11:10:41 2024 -0700 btf: emit symbol refs in DATASEC entries only for BPF [PR114608] The behavior introduced

[PATCH] btf: improve btf-datasec-3.c test [PR 114642]

This test failed on powerpc --target_board=unix'{-m32}' because two variables were not placed in sections where the test silently (and incorrectly) assumed they would be. The important thing for the test is only that BTF_KIND_DATASEC entries are NOT generated for the extern variable declarations

[PATCH] btf: emit symbol refs in DATASEC entries only for BPF [PR114608]

The behavior introduced in fa60ac54964 btf: Emit labels in DATASEC bts_offset entries. is only fully correct when compiling for the BPF target with BPF CO-RE enabled. In other cases, depending on optimizations, it can result in an incorrect symbol reference in the entry bts_offset field for a

Re: [PATCH] btf: Fix up btf-datasec-1.c test on x86

Hi Jakub, On 3/27/24 04:16, Jakub Jelinek wrote: > On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote: >>> -/* The offset entry for each variable in a DATSEC should be 0 at compile >>> time. */ >>> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */ >>> +/*

Re: [PATCH] btf: Emit labels in DATASEC bts_offset entries.

On 3/26/24 07:28, Cupertino Miranda wrote: > Hi everyone, > > This patch is an expected fix for the issue reported by systemd in: > https://github.com/systemd/systemd/issues/31888 > Also, Jose Marchesi opened the following bugzilla to report it: >

Re: [PATCH 3/3] bpf: Corrected index computation when present with unnamed struct fields

On 3/13/24 07:24, Cupertino Miranda wrote: > Any unnamed structure field if not a member of the BTF_KIND_STRUCT. typo: if -> is I'd suggest to clarify that "any unnamed structure field" is really any unnamed non-struct-or-union field, since anonymous inner structs and unions certainly are

Re: [PATCH 2/3] bpf: Fix access string default for CO-RE type based relocations

On 3/13/24 07:24, Cupertino Miranda wrote: > Although part of all CO-RE relocation data, type based relocations do > not require an access string. > Initial implementation defined it as an empty string. > On the other hand, libbpf when parsing the CO-RE relocations verifies > that those strings

Re: [PATCH] bpf: define INT8_TYPE as signed char

On 3/14/24 10:16, Jose E. Marchesi wrote: > > Hi David. > >> Change the BPF backend to define INT8_TYPE with an explicit sign, rather >> than a plain char. This is in line with other targets and removes the >> risk of int8_t being affected by the signedness of the plain char type >> of the

[gcc r14-9481] bpf: define INT8_TYPE as signed char

https://gcc.gnu.org/g:6cf4286ff9456685a29812a3560d00b956d62c39 commit r14-9481-g6cf4286ff9456685a29812a3560d00b956d62c39 Author: David Faust Date: Thu Mar 14 09:05:38 2024 -0700 bpf: define INT8_TYPE as signed char Change the BPF backend to define INT8_TYPE with an explicit sign

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] testsuite: ctf: make array in ctf-file-scope-1 fixed length

https://gcc.gnu.org/g:3eae1cdff0cf06bd21b51700e22d443110d0adad commit 3eae1cdff0cf06bd21b51700e22d443110d0adad Author: David Faust Date: Fri Mar 1 10:43:24 2024 -0800 testsuite: ctf: make array in ctf-file-scope-1 fixed length The array member of struct SFOO in the ctf-file-scope

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] bpf: add size threshold for inlining mem builtins

https://gcc.gnu.org/g:333445364ba7829dde7a9e8548a26c26eb979c21 commit 333445364ba7829dde7a9e8548a26c26eb979c21 Author: David Faust Date: Thu Mar 7 09:29:32 2024 -0800 bpf: add size threshold for inlining mem builtins BPF cannot fall back on library calls to implement memmove

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] bpf: testsuite: fix unresolved test in memset-1.c

https://gcc.gnu.org/g:64e6da250a07c19d302ec8648824cb42b608cf62 commit 64e6da250a07c19d302ec8648824cb42b608cf62 Author: David Faust Date: Thu Mar 7 09:23:38 2024 -0800 bpf: testsuite: fix unresolved test in memset-1.c The test was trying to do too much by both checking

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] ctf: fix incorrect CTF for multi-dimensional array types

https://gcc.gnu.org/g:f2cd7e1cb3d326ceb5af3e4629f1ab19dabe6d3f commit f2cd7e1cb3d326ceb5af3e4629f1ab19dabe6d3f Author: Cupertino Miranda Date: Thu Feb 29 10:56:13 2024 -0800 ctf: fix incorrect CTF for multi-dimensional array types PR debug/114186 DWARF DIEs of type

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] bpf: add inline memset expansion

https://gcc.gnu.org/g:548dbf6f87878800f214982e6c6d104b8a2a6ea1 commit 548dbf6f87878800f214982e6c6d104b8a2a6ea1 Author: David Faust Date: Mon Mar 4 09:35:01 2024 -0800 bpf: add inline memset expansion Similar to memmove and memcpy, the BPF backend cannot fall back on a library

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] bpf: renames coreout.* files to btfext-out.*.

https://gcc.gnu.org/g:5cb3615ed932faa521e2587c047b0771816c14aa commit 5cb3615ed932faa521e2587c047b0771816c14aa Author: Cupertino Miranda Date: Mon Feb 12 17:56:04 2024 + bpf: renames coreout.* files to btfext-out.*. gcc/ChangeLog: * config.gcc

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] bpf: implementation of func_info in .BTF.ext.

https://gcc.gnu.org/g:ab9ca7ee0825823e24048a1c213ef2dc587d6bc7 commit ab9ca7ee0825823e24048a1c213ef2dc587d6bc7 Author: Cupertino Miranda Date: Mon Feb 12 17:46:03 2024 + bpf: implementation of func_info in .BTF.ext. Kernel verifier complains in some particular cases for

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] bpf: Always emit .BTF.ext section if generating BTF

https://gcc.gnu.org/g:4583f84ba8e6729079e4ca5f745b4ebc58b27ab5 commit 4583f84ba8e6729079e4ca5f745b4ebc58b27ab5 Author: Cupertino Miranda Date: Mon Feb 12 17:37:37 2024 + bpf: Always emit .BTF.ext section if generating BTF BPF applications, when generating BTF information

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] btf: add BTF_KIND_FUNC traversal function.

https://gcc.gnu.org/g:1ab0c08b0885fa7549a635f9bae1422499562fc8 commit 1ab0c08b0885fa7549a635f9bae1422499562fc8 Author: Cupertino Miranda Date: Mon Feb 12 17:36:21 2024 + btf: add BTF_KIND_FUNC traversal function. The patch adds a traversal function to traverse all

[gcc(refs/users/dfaust/heads/gcc-13-bpf)] btf: fix type id in BTF_KIND_FUNC struct data.

https://gcc.gnu.org/g:193966aab3bba1ca27630a23f4b575c53be9af03 commit 193966aab3bba1ca27630a23f4b575c53be9af03 Author: Cupertino Miranda Date: Tue Jan 30 19:01:12 2024 + btf: fix type id in BTF_KIND_FUNC struct data. This patch corrects the addition of +1 on the type id,

[PATCH] bpf: define INT8_TYPE as signed char

Change the BPF backend to define INT8_TYPE with an explicit sign, rather than a plain char. This is in line with other targets and removes the risk of int8_t being affected by the signedness of the plain char type of the host system. Tested on x86_64-linux-gnu host for bpf-unknown-none. Sanity

[gcc r14-9400] bpf: add size threshold for inlining mem builtins

https://gcc.gnu.org/g:0e850eff58539fb79483664962fac6c46d65c79d commit r14-9400-g0e850eff58539fb79483664962fac6c46d65c79d Author: David Faust Date: Thu Mar 7 09:29:32 2024 -0800 bpf: add size threshold for inlining mem builtins BPF cannot fall back on library calls to implement

[PATCH v2] bpf: add size threshold for inlining mem builtins

[Changes from v1: - Error if threshold is exceeded instead of silently emitting libcall - Update test accordingly - Expand documentation to explain this behavior ] BPF cannot fall back on library calls to implement memmove, memcpy and memset, so we attempt to expand these inline always if

[gcc r14-9398] bpf: testsuite: fix unresolved test in memset-1.c

https://gcc.gnu.org/g:10c609191c4462133d6a4ea10a739167204f2cd3 commit r14-9398-g10c609191c4462133d6a4ea10a739167204f2cd3 Author: David Faust Date: Thu Mar 7 09:23:38 2024 -0800 bpf: testsuite: fix unresolved test in memset-1.c The test was trying to do too much by both checking

[PATCH] bpf: testsuite: fix unresolved test in memset-1.c

The test was trying to do too much by both checking for an error, and checking the resulting assembly. Of course, due to the error no asm was produced, so the scan-asm went unresolved. Split it into two separate tests to fix the issue. Tested on x86_64-linux-gnu host for bpf-unknown-none target.

[PATCH] bpf: add size threshold for inlining mem builtins

BPF cannot fall back on library calls to implement memmove, memcpy and memset, so we attempt to expand these inline always if possible. However, this inline expansion was being attempted even for excessively large operations, which could result in gcc consuming huge amounts of memory and hanging.

Re: [PATCH, V3] ctf: fix incorrect CTF for multi-dimensional array types

On 3/5/24 00:47, Indu Bhagat wrote: > From: Cupertino Miranda > > [Changes from V2] > - Fixed aarch64 new FAILs reported by Linaro CI. > - Fixed typos and other nits pointed out in V2. > [End of changes from V2] OK, thanks. > > PR debug/114186 > > DWARF DIEs of type

Re: [PATCH,V2] ctf: fix incorrect CTF for multi-dimensional array types

Hi Indu, Cupertino, On 3/4/24 10:00, Indu Bhagat wrote: > From: Cupertino Miranda > > [Changes from V1] > - Refactor the code a bit. > [End of changes from V1] > > PR debug/114186 > > DWARF DIEs of type DW_TAG_subrange_type are linked together to represent > the information about the

[PATCH] bpf: add inline memset expansion

Similar to memmove and memcpy, the BPF backend cannot fall back on a library call to implement __builtin_memset, and should always expand calls to it inline if possible. This patch implements simple inline expansion of memset in the BPF backend in a verifier-friendly way. Similar to memcpy and

[PATCH] testsuite: ctf: make array in ctf-file-scope-1 fixed length

The array member of struct SFOO in the ctf-file-scope-1 caused the test to fail for the BPF target, since BPF does not support dynamic stack allocation. The array does not need to variable length for the sake of the test, so make it fixed length instead to allow the test to run successfully for

Re: [PATCH v2 4/5] bpf: implementation of func_info in .BTF.ext.

Hi Cupertino, On 2/27/24 11:04, Cupertino Miranda wrote: > Kernel verifier complains in some particular cases for missing func_info > implementation in .BTF.ext. This patch implements it. > > Strings are cached locally in coreout.cc to avoid adding duplicated > strings in the string list. This

Re: [PATCH v2 5/5] bpf: renamed coreout.* files to btfext-out.*.

On 2/27/24 11:04, Cupertino Miranda wrote: > gcc/ChangeLog: > > * config.gcc (target_gtfiles): Changes coreout to btfext-out. > (extra_objs): Changes coreout to btfext-out. > * config/bpf/coreout.cc: Renamed to btfext-out.cc. > * config/bpf/btfext-out.cc: Added. > *

Re: [PATCH v2 3/5] bpf: Always emit .BTF.ext section if generating BTF

On 2/27/24 11:04, Cupertino Miranda wrote: > BPF applications, when generating BTF information should always create a > .BTF.ext section. > Current implementation was only creating it when -mco-re option was used. > This patch makes .BTF.ext always be generated for BPF target objects. > The

Re: [PATCH v2 2/5] btf: added KIND_FUNC traversal function.

Hi Cupertino, Similar to patch 1, please use present tense to match the style of existing commits, in commit message and in ChangeLog. On 2/27/24 11:04, Cupertino Miranda wrote: > Added a traversal function to traverse all BTF_KIND_FUNC nodes with a > callback function. Used for .BTF.ext section

Re: [PATCH v2 1/5] btf: fixed type id in BTF_KIND_FUNC struct data.

Hi Cupertino, Just some nits below. Apologies for incoming pedantry. On 2/27/24 11:04, Cupertino Miranda wrote: > This patch correct the aditition of +1 on the type id, which originally > was done in the wrong location and leaded to func_sts->dtd_type for > BTF_KIND_FUNCS struct data to contain

Re: [PATCH 5/5] bpf: renamed coreout.* files to btfext-out.*.

On 2/20/24 02:24, Cupertino Miranda wrote: > gcc/ChangeLog: > * config.gcc (target_gtfiles): changed coreout to btfext-out. > (extra_objs): changed coreout to btfext-out. I think these entries should start with a capital letter ("Changed..."). > * config/bpf/coreout.cc:

Re: [PATCH 2/5] btf: added KIND_FUNC traversal function.

On 2/20/24 02:24, Cupertino Miranda wrote: > Added a traversal function to traverse all BTF_KIND_FUNC nodes with a > callback function. Used for .BTF.ext section content creation. > > gcc/ChangeLog > > * btfout.cc (output_btf_func_types): use FOR_EACH_VEC_ELT. >

[PATCH v3] bpf: add inline memmove and memcpy expansion

[Changes from v2: - Fix incorrectly passing a location instead of OPT_W* for warning (). - Reword warning/error message and test accordingly. ] [Changes from v1: Jose's review comments, all of which I agree with. - Fix 'implments' typo in commit message. - Change check that alignment is

Re: [PATCH v2] bpf: add inline memmove and memcpy expansion

On 2/20/24 12:37, Jose E. Marchesi wrote: > > Hi Faust. > >> +bool >> +bpf_expand_cpymem (rtx *operands, bool is_move) >> +{ >> + /* Size must be constant for this expansion to work. */ >> + if (!CONST_INT_P (operands[2])) >> +{ >> + const char *name = is_move ? "memmove" :

Re: [PATCH 3/5] btf: moved btf deallocation to final.

Hi Cupertino, On 2/20/24 02:24, Cupertino Miranda wrote: > Dissociated .BTF.ext from the CO-RE relocations creation. Improvement of > allocation/deallocation of BTF structures. Moving deallocation to final > when needed. > > gcc/ChangeLog: > > * config/bpf/bpf.cc (bpf_option_override):

Re: [PATCH 1/5] btf: fixed type id in BTF_KIND_FUNC struct data.

On 2/20/24 02:24, Cupertino Miranda wrote: > This patch correct the aditition of +1 on the type id, which originally > was done in the wrong location and leaded to func_sts->dtd_type for > BTF_KIND_FUNCS struct data to contain the type id of the previous entry. > > gcc/ChangeLog: > *

[PATCH v2] bpf: add inline memmove and memcpy expansion

[Changes from v1: Jose's review comments, all of which I agree with. - Fix 'implments' typo in commit message. - Change check that alignment is CONST_INT to gcc_assert (). - Change default case in alignment switch to gcc_unreachable (). - Reword error message for non-constant size

[PATCH] bpf: add inline memmove and memcpy expansion

BPF programs are not typically linked, which means we cannot fall back on library calls to implement __builtin_{memmove,memcpy} and should always expand them inline if possible. GCC already successfully expands these builtins inline in many cases, but failed to do so for a few for simple cases

[PATCH] bpf: fix zero_extendqidi2 ldx template

Commit 77d0f9ec3809b4d2e32c36069b6b9239d301c030 inadvertently changed the normal asm dialect instruction template for zero_extendqidi2 from ldxb to ldxh. Fix that. Tested for bpf-unknown-none on x86_64-linux-gnu host. gcc/ * config/bpf/bpf.md (zero_extendqidi2): Correct asm template to

Re: [PATCH] bpf: Correct BTF for kernel_helper attributed decls.

Hi Cupetino, On 1/8/24 03:05, Cupertino Miranda wrote: > Hi everyone, > > This patch address the problem reported in: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 > > Looking forward to your review. LGTM, thanks. Please apply. > > Cheers, > Cupertino > > > This patch fix a problem

Re: [PATCH] btf: print string position as comment for validation and testing purposes.

Hi Cupertino, On 1/8/24 02:55, Cupertino Miranda wrote: > Hi everyone, > > This patch adds a comment to the BTF strings regarding their position > within the section. This is useful for assembly inspection purposes. > > Regards, > Cupertino > > When using -dA, this function was only printing

[PATCH] btf: change encoding of forward-declared enums [PR111735]

The BTF specification does not formally define a representation for forward-declared enum types such as: enum Foo; Forward-declarations for struct and union types are represented by BTF_KIND_FWD, which has a 1-bit flag distinguishing the two. The de-facto standard format used by other tools

Re: [PATCH] btf: avoid wrong DATASEC entries for extern vars [PR112849]

On 12/5/23 13:28, Indu Bhagat wrote: > On 12/4/23 15:47, David Faust wrote: >> The process of creating BTF_KIND_DATASEC records involves iterating >> through variable declarations, determining which section they will be >> placed in, and creating an entry in the appro

[PATCH] btf: avoid wrong DATASEC entries for extern vars [PR112849]

The process of creating BTF_KIND_DATASEC records involves iterating through variable declarations, determining which section they will be placed in, and creating an entry in the appropriate DATASEC record accordingly. For variables without e.g. an explicit __attribute__((section)), we use

Re: [PATCH] btf: fix PR debug/112768

On 11/30/23 14:17, Indu Bhagat wrote: > PR debug/112768 - btf: fix asm comment output for BTF_KIND_FUNC* kinds > > The patch adds a small function to abstract out the detail and return > the name of the type. The patch also fixes the issue of BTF_KIND_FUNC > appearing in the comments with a

Re: [PATCH] btf: fix PR debug/112656

Hi Indu, On 11/30/23 14:18, Indu Bhagat wrote: > PR debug/112656 - btf: function prototypes generated with name > > With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the > generated BTF section. > > As noted in the discussion in the bugzilla, the number of > BTF_KIND_FUNC_PROTO

[PATCH] bpf: change ASM_COMMENT_START to '#'

The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate statements, not to begin line comments. The GNU assembler was recently changed accordingly: https://sourceware.org/pipermail/binutils/2023-November/130867.html This patch adapts the BPF backend in GCC accordingly, to use a

Re: [PATCH v2] Fixed problem with BTF defining smaller enums.

Hi Cupertino, On 11/27/23 09:21, Cupertino Miranda wrote: > Hi everyone, > > David: Thanks for the v1 review. > > This version adds the following; > - test case, > - improves condition logic, > - fixes mask typo. > > Looking forward to your review. v2 LGTM, please apply. Thanks! > > v1

  1   2   3   >