Re: [PATCH] bpf: create modifier for mem operand for xchg and cmpxchg

Fixed and pushed! Thanks, Cupertino David Faust writes: > 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 sh

[gcc r15-2153] bpf: create modifier for mem operand for xchg and cmpxchg

https://gcc.gnu.org/g:8fbc386c12385378b01a744c6764b5660d4b4310 commit r15-2153-g8fbc386c12385378b01a744c6764b5660d4b4310 Author: Cupertino Miranda Date: Thu Jul 11 15:28:09 2024 +0100 bpf: create modifier for mem operand for xchg and cmpxchg Both xchg and cmpxchg instructions

[PATCH] bpf: create modifier for mem operand for xchg and cmpxchg

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 patch implements an operand modifier 'M'

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

David Faust writes: > 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 com

Re: [PATCH 1/3] bpf: support more instructions to match CO-RE relocations

Thanks! Pushed! Jose E. Marchesi writes: > Hi Cupertino. > OK for master. > Thanks! > >> BPF supports multiple instructions to be CO-RE relocatable regardless of >> the position of the immediate field in the encoding. >> In particular, not only the MOV instruction allows a CO-RE >> relocation

[gcc r14-10038] bpf: remove huge memory waste with string allocation.

https://gcc.gnu.org/g:ede01dfd9dd85e03dea30402e773c62f0408adbe commit r14-10038-gede01dfd9dd85e03dea30402e773c62f0408adbe Author: Cupertino Miranda Date: Tue Apr 2 12:04:28 2024 +0100 bpf: remove huge memory waste with string allocation. The BPF backend was allocating

[gcc r14-10037] bpf: support more instructions to match CO-RE relocations

https://gcc.gnu.org/g:d7190d0b9a8e395f46b475e4d525f2b6a0ce4df4 commit r14-10037-gd7190d0b9a8e395f46b475e4d525f2b6a0ce4df4 Author: Cupertino Miranda Date: Wed Mar 20 19:06:47 2024 + bpf: support more instructions to match CO-RE relocations BPF supports multiple instructions

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

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. Thanks for the quick and detailed reviews. Regards, Cupertino The

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

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/bpf/core-builtins.cc | 10 ++ 1 file changed, 6

Re: [PATCH 3/3] bpf: add line_info support to BTF.ext section.

Jose E. Marchesi writes: > Hi Cuper. > Thanks for the patch. > >> This patch adds line_info debug information support to .BTF.ext >> sections. >> Line info information is used by the BPF verifier to improve error >> reporting and give more precise source core referenced errors. >> >>

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

Hi David, Thanks for the review. Will apply the changes. Nice catch and optimization with the vlen size. Cupertino David Faust writes: > Hi Cupertino, > > On 4/11/24 04:11, Cupertino Miranda wrote: >> Code was allocating way too much space for the string. > > A little

[PATCH 3/3] bpf: add line_info support to BTF.ext section.

This patch adds line_info debug information support to .BTF.ext sections. Line info information is used by the BPF verifier to improve error reporting and give more precise source core referenced errors. gcc/Changelog: * config/bpf/bpf-protos.h (bpf_output_call): Change prototype.

[PATCH 1/3] bpf: support more instructions to match CO-RE relocations

BPF supports multiple instructions to be CO-RE relocatable regardless of the position of the immediate field in the encoding. In particular, not only the MOV instruction allows a CO-RE relocation of its immediate operand, but the LD and ST instructions can have a CO-RE relocation happening to

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

Code was allocating way too much space for the string. gcc/ChangeLog: * config/bpf/core-builtins.cc (process_enum_value): Corrected string allocation. --- gcc/config/bpf/core-builtins.cc | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

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

Hi Jakub, Thanks for the patch and appologies for the results regression. Cupertino Jakub Jelinek writes: > On Tue, Mar 26, 2024 at 02:28:52PM +0000, Cupertino Miranda wrote: >> GCC was defining bts_offset entry to always contain 0. >> When comparing with clang, the same e

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

David Faust writes: > 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

[gcc r14-9677] btf: Emit labels in DATASEC bts_offset entries.

https://gcc.gnu.org/g:fa60ac549649655a3f55e69f83d2e97423d3eb5c commit r14-9677-gfa60ac549649655a3f55e69f83d2e97423d3eb5c Author: Cupertino Miranda Date: Tue Mar 26 11:59:47 2024 + btf: Emit labels in DATASEC bts_offset entries. GCC was defining bts_offset entry to always

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

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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 Please notice that the function created was

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

David Faust writes: > 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 fi

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

David Faust writes: > 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 pa

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

> This patch corrects bugs within the CO-RE builtin field expression > related builtins. > The following bugs were identified and corrected based on the expected > results of bpf-next selftests testsuite. > It addresses the following problems: > - Expressions with

[gcc r14-9585] bpf: Corrected index computation when present with unnamed struct fields

https://gcc.gnu.org/g:f10c18df9c02dc518360426c021971838e0012d2 commit r14-9585-gf10c18df9c02dc518360426c021971838e0012d2 Author: Cupertino Miranda Date: Fri Mar 8 13:33:42 2024 + bpf: Corrected index computation when present with unnamed struct fields Any unnamed non-struct

[gcc r14-9584] bpf: Fix access string default for CO-RE type based relocations

https://gcc.gnu.org/g:624d025f62fdbc969cca08fdb1ac77246b8535a5 commit r14-9584-g624d025f62fdbc969cca08fdb1ac77246b8535a5 Author: Cupertino Miranda Date: Tue Mar 5 11:53:56 2024 + bpf: Fix access string default for CO-RE type based relocations Although part of all CO-RE

[gcc r14-9583] bpf: Fix CO-RE field expression builtins

https://gcc.gnu.org/g:8e913b5c0c998b2ae9497a6ff6bdf475c136cd97 commit r14-9583-g8e913b5c0c998b2ae9497a6ff6bdf475c136cd97 Author: Cupertino Miranda Date: Tue Jan 30 15:55:18 2024 + bpf: Fix CO-RE field expression builtins This patch corrects bugs within the CO-RE builtin field

Re: [PATCH 1/3] bpf: Fix CO-RE field expression builtins

Jose E. Marchesi writes: >> This patch corrects bugs within the CO-RE builtin field expression >> related builtins. >> The following bugs were identified and corrected based on the expected >> results of bpf-next selftests testsuite. >> It addresses the following problems: >> - Expressions

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

Any unnamed structure field if not a member of the BTF_KIND_STRUCT. For that reason, CO-RE access strings indexes should take that in consideration. This patch adds a condition to the incrementer that computes the index for the field access. gcc/ChangeLog: * config/bpf/core-builtins.cc

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

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 would contain "0", otherwise reports an error. This

[PATCH 1/3] bpf: Fix CO-RE field expression builtins

This patch corrects bugs within the CO-RE builtin field expression related builtins. The following bugs were identified and corrected based on the expected results of bpf-next selftests testsuite. It addresses the following problems: - Expressions with pointer dereferencing now point to the BTF

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

Corrected and Pushed. Thanks, Cupertino David Faust writes: > 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. >>

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

NULL) \ { \ Thanks, Cupertino David Faust writes: > 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. >> >> Str

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

Corrected and Pushed. Thanks, Cupertino David Faust writes: > 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 wa

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

Corrected and Pushed. Thanks, Cupertino David Faust writes: > 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 traver

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

Corrected and Pushed. Thanks, Cupertino David Faust writes: > 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

[PATCH] ctf: Fix multi-dimentional array types ordering in CTF

Hi everyone, In order to facilitate reviewing, I include a copy of the function in this email, since the code structure changes are too hard to analyse in the patch itself. Looking forward to your comments. Regards, Cupertino === Function changes === /* Generate CTF for an ARRAY_TYPE. C

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

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. * config/bpf/coreout.h: Renamed to btfext-out.h.

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

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 string deduplication should eventually be moved to the CTFC functions

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

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 patch also adds conditions around btf_finalize function

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

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. (traverse_btf_func_types): Defined function. * ctfc.h

bpf: PR target/113453 func_info .BTF.ext implementation

Hi everyone, Just an updated version of the patches based on recent reviews from David Faust. Thanks for the feedback. Regards, Cupertino

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

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: * btfout.cc (btf_collect_dataset): Corrected BTF type id.

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

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 string deduplication should eventually be moved to the CTFC functions

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

gcc/ChangeLog: * config.gcc (target_gtfiles): changed coreout to btfext-out. (extra_objs): changed coreout to btfext-out. * config/bpf/coreout.cc: Renamed to btfext-out.cc * config/bpf/btfext-out.cc: Added * config/bpf/coreout.h: Renamed to btfext-out.h

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

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): Make BTF.ext enabled by default for BPF.

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

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. (traverse_btf_func_types): Defined function. * ctfc.h

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

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: * btfout.cc (btf_collect_dataset): Corrected BTF type id. ---

bpf: PR target/113453 func_info .BTF.ext implementation

Good morning, This is a patch series with the implementation of func_info region within bpf target .BTF.ext section. Considering the required changes it also implied some changes in BTF and in the original CO-RE implementation, more specifically the structure used and how the relocations were

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

Thanks! Committed. David Faust writes: > 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 purp

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

Thanks! Committed. David Faust writes: > 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 t

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

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 as comment btf_string or btf_aux_string. This patch changes the comment to

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

Hi everyone, This patch address the problem reported in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 Looking forward to your review. Cheers, Cupertino This patch fix a problem with kernel_helper attribute BTF information, which incorrectly generates BTF_KIND_FUNC entry. This BTF entry

Re: bpf: Throw error when external libcalls are generated.

Please revert: > > commit faf5b148588bd7fbb60ec669aefa704044037cdc > Author: Cupertino Miranda > Date: Thu Nov 23 22:28:01 2023 + > > Thanks! > >> >>> Hi everyone, >>> >>> The attached patch is a temporary solution for the lack of proper linker >>> and extern

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

Thanks! Committed! David Faust writes: > 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

Re: [PATCH] bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.

Thanks! Committed! Jose E. Marchesi writes: > Hi Cuper. > > Sorry, I missed this patch last week. > This is OK. > > Thanks! > >> This patch forces __builtin_memcmp calls upto data sizes of 1024 to >> become inline in caller. >> This is a requirement by BPF and it mimics the default behaviour

Re: [PATCH] bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.

Thanks! Committed ! Jose E. Marchesi writes: > Hi Cuper. > > Sorry, I missed this patch last week. > This is OK. > > Thanks! > >> This patch forces __builtin_memcmp calls upto data sizes of 1024 to >> become inline in caller. >> This is a requirement by BPF and it mimics the default behaviour

Re: [PATCH] bpf: Corrected condition in core_mark_as_access_index.

Thanks! Committed ! David Faust writes: > On 11/13/23 14:36, Cupertino Miranda wrote: >> gcc/ChangeLog: >> * config/bpf/core-builtins.cc (core_mark_as_access_index): >> Corrected check. > > OK, thanks. > >> --- >> gcc/config/bpf/cor

Re: [PATCH] bpf: Delayed the removal of the parser enum plugin handler.

Thanks!! Commited ! David Faust writes: > On 11/13/23 14:35, Cupertino Miranda wrote: >> The parser plugin handler that is responsible for collecting enum values >> information was being removed way too early. >> bpf_resolve_overloaded_core_builtin is called by the pa

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

3f89d352a4ee90882089142d743f8a748013b5fe Author: Cupertino Miranda Date: Fri Nov 10 14:02:30 2023 + Fixed problem with BTF defining smaller enums. This patch fixes a BTF, which would become invalid when having smaller then 4 byte definitions of enums. For example, when using

bpf: Throw error when external libcalls are generated.

User-agent: mu4e 1.4.15; emacs 28.1 Author: Cupertino Miranda Hi everyone, The attached patch is a temporary solution for the lack of proper linker and external library linking of the eBPF platform. Any calls created by the compiler, that would usually be defined within libgcc, will endup

bpf: Throw error when external libcalls are generated.

. This patch anticipates that error to the compiler, by verifiying if any of those calls are being generated, and reporting as an error. Looking forward to your comments. Cheers, Cupertino commit c2110ae497c7ff83c309f172bc265973652b760d Author: Cupertino Miranda Date: Thu Nov 23 22:28:01 2023

[PATCH] Fixed problem with BTF defining smaller enums.

This patch fixes a BTF, which would become invalid when having smaller then 4 byte definitions of enums. For example, when using the __attribute__((mode(byte))) in the enum definition. Two problems were identified: - it would incorrectly create an entry for enum64 when the size of the enum

[PATCH] bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.

This patch forces __builtin_memcmp calls upto data sizes of 1024 to become inline in caller. This is a requirement by BPF and it mimics the default behaviour of the clang BPF implementation. gcc/ChangeLog: * config/bpf/bpf.cc (bpf_use_by_pieces_infrastructure_p): Added function to

[PATCH] bpf: Corrected condition in core_mark_as_access_index.

gcc/ChangeLog: * config/bpf/core-builtins.cc (core_mark_as_access_index): Corrected check. --- gcc/config/bpf/core-builtins.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/bpf/core-builtins.cc b/gcc/config/bpf/core-builtins.cc index

[PATCH] bpf: Delayed the removal of the parser enum plugin handler.

The parser plugin handler that is responsible for collecting enum values information was being removed way too early. bpf_resolve_overloaded_core_builtin is called by the parser. It was moved to the function execute_lower_bpf_core. gcc/ChangeLog: * config/bpf/core-builtins.cc

Re: [PATCH v5] bpf: Improvements in CO-RE builtins implementation.

> On 10/31/23 09:58, David Faust wrote: >> Hi Cupertino, >> >> On 10/30/23 12:39, Cupertino Miranda wrote: >>> >>> Hi everyone, >>> >>> Please find a new version for the review as inline attachment. >>> >>> Best rega

[PATCH v5] bpf: Improvements in CO-RE builtins implementation.

5b45d225c473827b5ef7001e5b24df74d27953ff Author: Cupertino Miranda Date: Tue Aug 8 09:22:41 2023 +0100 bpf: Improvements in CO-RE builtins implementation. This patch moved the processing of attribute preserve_access_index to its own independent pass in a gimple lowering pass. This approach is more

Re: [PATCH v4] bpf: Improvements in CO-RE builtins implementation.

Hi David, David Faust writes: > On 10/26/23 08:08, Cupertino Miranda wrote: >> >> Changes from v1: >> - Fixed Davids remarks on initial patch. >> - Fixed mistake with deleted '*'. >> >> Changes from v2: >> - Reversed return value for b

[PATCH v4] bpf: Improvements in CO-RE builtins implementation.

lhs) - core_mark_as_access_index (gimple_get_lhs (wi->stmt)); + tree lhs; + if (!wi->is_lhs + && (lhs = gimple_get_lhs (wi->stmt)) != NULL_TREE) + core_mark_as_access_index (lhs); commit b525feaeb159f55c2a6db1cb4246bd027351f2c5 Author: Cupertino Miranda Date:

Re: [PATCH v3] bpf: Improvements in CO-RE builtins implementation.

Changes from v2: - Reversed return value for bpf_const_not_ok_for_debug_p function. commit 3a0b09273727a49fab7461d059d504899bb6556d Author: Cupertino Miranda Date: Tue Aug 8 09:22:41 2023 +0100 bpf: Improvements in CO-RE builtins implementation. This patch moved the processing

Re: [PATCH v2] bpf: Improvements in CO-RE builtins implementation.

xpressions assigned to > the variable. In fact, this does not compile. > It was an editor mistake ... caused by the editor sitting in a chair. ;-) Apologies for this mistake and thanks for catching it. Thanks, Cupertino commit 687b67d82c7d8c6cf5b0e3a9dc61fd4f1e1a1fbb Author: C

Re: [PATCH] bpf: Improvements in CO-RE builtins implementation.

51, Cupertino Miranda wrote: >> Hi everyone, >> >> This patch contains some more recent improvements to BPF CO-RE builtins. >> Please find further details of the changes on the patch header. >> >> Looking forward for your review and comments. >> >> Be

[PATCH] bpf: Improvements in CO-RE builtins implementation.

Hi everyone, This patch contains some more recent improvements to BPF CO-RE builtins. Please find further details of the changes on the patch header. Looking forward for your review and comments. Best regards, Cupertino Miranda commit 6054209c0a8af9c3e6363550bf2ba4f4f2172eba Author: Cupertino

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

though) > > On Thu, Aug 03, 2023 at 10:54:31AM +0100, Cupertino Miranda wrote: >> [snip] >> + >> +pack_type_fail: >> + bpf_error_at (EXPR_LOC_OR_LOC (args[0], UNKNOWN_LOCATION), >> +"invelid first argument format for enum value bu

Re: [PATCH] bpf: Fixed GC mistakes in BPF builtins code.

pilation unit. >> >> Fault was triggered when attempting to compile some BPF kernel big >> examples that revealed the lack of GC information. >> >> Patch also removes some spurious includes of header files. >> >> Best regards, >> Cupertino >>

[PATCH] bpf: Fixed GC mistakes in BPF builtins code.

the compilation unit. Fault was triggered when attempting to compile some BPF kernel big examples that revealed the lack of GC information. Patch also removes some spurious includes of header files. Best regards, Cupertino commit c71b5c604189d04664c5b5ee155326fa4b79808b Author: Cupertino Miranda Date

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

gt; From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17 00:00:00 2001 >> From: Cupertino Miranda >> Date: Thu, 27 Jul 2023 18:05:22 +0100 >> Subject: [PATCH v2 2/2] bpf: CO-RE builtins support tests. >> >> This patch adds tests for the following builtins: &g

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Pushed to upstream master. Thanks ! Jose E. Marchesi writes: > Ok. > Thanks! > >> From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 >> From: Cupertino Miranda >> Date: Thu, 6 Apr 2023 15:22:48 +0100 >> Subject: [PATCH v2 1/2] bpf: Imp

Re: [v2 PATCH 2/2] bpf: CO-RE builtins support tests.

Hi, Resending this patch since I have noticed I had a testcase added in previous patch. Makes more sense here. Thanks, Cupertino >From 334e9ae0f428f6573f2a5e8a3067a4d181b8b9c5 Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Thu, 27 Jul 2023 18:05:22 +0100 Subject: [PATCH v2 2/2]

Re: [v2 PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

>From fda9603ded735205b6e20fc5b65a04f8d15685e6 Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Thu, 6 Apr 2023 15:22:48 +0100 Subject: [PATCH v2 1/2] bpf: Implementation of BPF CO-RE builtins This patch updates the support for the BPF CO-RE builtins __builtin_preserve_access_in

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

>> + /* FIXED: This wat not Ok. > > Hm? If that is fixed, do we still need that comment? :) Touche! ;) > >> +emit_insn ( \ >> + gen_mov_reloc_coredi (reg, \ >> +gen_rtx_CONST_INT (Pmode, 0), \ >> +

Re: [PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

Jose E. Marchesi writes: >> This patch updates the support for the BPF CO-RE builtins >> __builtin_preserve_access_index and __builtin_preserve_field_info, >> and adds support for the CO-RE builtins __builtin_btf_type_id, >> __builtin_preserve_type_info and __builtin_preserve_enum_value. >> >>

[PATCH 1/2] bpf: Implementation of BPF CO-RE builtins

This patch updates the support for the BPF CO-RE builtins __builtin_preserve_access_index and __builtin_preserve_field_info, and adds support for the CO-RE builtins __builtin_btf_type_id, __builtin_preserve_type_info and __builtin_preserve_enum_value. These CO-RE relocations are now converted to

[PATCH 2/2] bpf: CO-RE builtins support tests.

This patch adds tests for the following builtins: __builtin_preserve_enum_value __builtin_btf_type_id __builtin_preserve_type_info --- .../gcc.target/bpf/core-builtin-enumvalue.c | 52 + .../bpf/core-builtin-enumvalue_errors.c | 22

[PATCH] CO-RE BPF builtins support

Hi everyone, This patch series implements all the BPF CO-RE builtins. It improves the support for __builtin_preserve_access_index and __builtin_preserve_field_info, but also introduces the support for __builtin_btf_type_id, __builtin_btf_preserve_type_info and __builtin_preserve_enum_value.

Re: [PATCH v3] bpf: pseudo-c assembly dialect support

>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index 3063e71c8906..b3be65d3efae 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -946,8 +946,8 @@ Objective-C and Objective-C++ Dialects}. >> >> @emph{eBPF Options} >> @gccoptlist{-mbig-endian -mlittle-endian

Re: [COMMITTED] bpf: fixed template for neg (added second operand)

This patch fixes define_insn for "neg" to support 2 operands. Initial implementation assumed the format "neg %0" while the instruction allows both a destination and source operands. The second operand can either be a register or an immediate value. gcc/ChangeLog: * config/bpf/bpf.md:

[PATCH v4] bpf: fixed template for neg (added second operand)

This patch fixes define_insn for "neg" to support 2 operands. Initial implementation assumed the format "neg %0" while the instruction allows both a destination and source operands. The second operand can either be a register or an immediate value. gcc/ChangeLog: * config/bpf/bpf.md:

[COMMITTED] MAINTAINERS: Add myself to write after approval

Hi everyone, Just to confirm that I pushed the change in MAINTAINERS file, adding myself to the write after approval list. Thanks, Cupertino

Re: [PATCH v3] bpf: fixed template for neg (added second operand)

>From 7756a4becd1934e55d6d14ac4a9fd6d408a4797b Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Fri, 21 Jul 2023 17:40:07 +0100 Subject: [PATCH v3] bpf: fixed template for neg (added second operand) gcc/ChangeLog: * config/bpf/bpf.md: fixed template for neg instruction. --- gcc/con

Re: [PATCH v2] bpf: fixed template for neg (added second operand)

>From 9db2044c1d20bd9f05acf3c910ad0ffc9d5fda8f Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Fri, 21 Jul 2023 17:40:07 +0100 Subject: [PATCH v2] bpf: fixed template for neg (added second operand) gcc/ChangeLog: * config/bpf/bpf.md: fixed template for neg instruction. --- gcc/con

[PATCH] bpf: fixed template for neg (added second operand)

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 index 329f62f55c33..bb414d8a4428 100644 --- a/gcc/config/bpf/bpf.md +++

Re: [PATCH v3] bpf: pseudo-c assembly dialect support

> > Please make sure to run the contrib/gcc-changelog/git_check-commit.py > script. > >From 6ebe3229a59b32ffb2ed24b3a2cf8c360a807c31 Mon Sep 17 00:00:00 2001 From: Cupertino Miranda Date: Mon, 17 Jul 2023 17:42:42 +0100 Subject: [PATCH v3] bpf: pseudo-c assembly dialect support New

Re: [PATCH v2] bpf: pseudo-c assembly dialect support

e supported values. Can you > please add it and re-submit? > > >> Hi everyone, >> >> Looking forward to all your reviews. >> >> Best regards, >> Cupertino >From fa227fefd84e6eaaf8edafed698e9960d7b115e6 Mon Sep 17 00:00:00 2001 From: Cupertino Mira

[PATCH] bpf: pseudo-c assembly dialect support

Hi everyone, Looking forward to all your reviews. Best regards, Cupertino New pseudo-c BPF assembly dialect already supported by clang and widely used in the linux kernel. gcc/ChangeLog: * config/bpf/bpf.opt: Added option -masm=. * config/bpf/bpf-opts.h: Likewize. *

Re: [PATCH 2/2] Corrected pr25521.c target matching.

Cupertino Miranda via Gcc-patches writes: >> On 1/24/23 05:24, Cupertino Miranda wrote: >>> Thank you for the comments and suggestions. >>> I have changed the patch. >>> Unfortunately in case of rx target I could not make >>> scan-assembler-symbol

Re: [PATCH 2/2] Corrected pr25521.c target matching.

> On 1/24/23 05:24, Cupertino Miranda wrote: >> Thank you for the comments and suggestions. >> I have changed the patch. >> Unfortunately in case of rx target I could not make >> scan-assembler-symbol-section to match. I believe it is because the >> .section and

Re: [PING, PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

[PING] Cupertino Miranda writes: > Hi Jeff, > > Please, please, give me some feedback on this one. > I just don't want to have to keep asking you for time on this small > pending patches that I also have to keep track on. > > I realized your committed the other one.

Re: [PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

Hi Jeff, Please, please, give me some feedback on this one. I just don't want to have to keep asking you for time on this small pending patches that I also have to keep track on. I realized your committed the other one. Thank you ! Best regards, Cupertino Cupertino Miranda writes: > P

Re: [PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

PING ! Cupertino Miranda via Gcc-patches writes: > Hi Jeff, > > Can you please confirm if the patch is Ok? > > Thanks, > Cupertino > >> Cupertino Miranda via Gcc-patches writes: >> >>> Thank you for the comments and suggestions. >>> I ha

Re: [PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

Hi Jeff, Can you please confirm if the patch is Ok? Thanks, Cupertino > Cupertino Miranda via Gcc-patches writes: > >> Thank you for the comments and suggestions. >> I have changed the patch. >> >> Unfortunately in case of rx target I could not make >> sc

[PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

Cupertino Miranda via Gcc-patches writes: > Thank you for the comments and suggestions. > I have changed the patch. > > Unfortunately in case of rx target I could not make > scan-assembler-symbol-section to match. I believe it is because the > .section and .global entries

  1   2   >