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
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
the expressions 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
Auth
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
wi->is_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 Miran
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 v
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
> 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
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 st
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 patc
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 (bp
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 with
> 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
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
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-uni
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 inspired
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
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 ent
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 a/gcc/config/bpf/core
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 their
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.
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
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 crea
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.
---
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 (funcs_traver
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.
(btf_asm_init_se
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
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
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.
---
Hi everyone,
Just an updated version of the patches based on recent reviews from
David Faust.
Thanks for the feedback.
Regards,
Cupertino
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 (funcs_trave
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 call
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.
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
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 arg
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
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
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
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.
>>
>> String
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.
>> *
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
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 al
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
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
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
(bpf_
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 2ba78d7aed2e..1
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
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 was
.
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
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
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 the
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 parse
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
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 o
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 of
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 log
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
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' whi
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
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.
>>
>> gcc/Changel
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 ins
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
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 o
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
functions were not clobbering blink.
Looking forward to your reviews.
Best regards,
Cupertino
From 213a0f115b2c7459b2a65728f4c5a74d2ed89c9d Mon Sep 17 00:00:00 2001
From: Cupertino Miranda
Date: Mon, 4 Sep 2017 14:24:51 +0200
Subject: [PATCH] Fix to unwinding. Now is is possible to unwind from
Hi Claudiu and Andrew
This patches solves the dejagnu PIE failing tests.
Looking forward to your review.
Best regards,
Cupertino
gcc/
2016-07-27 Cupertino Miranda
* config/arc/arc.h (STARTFILE_SPEC): Use default linux specs.
(ENDFILE_SPEC): Likewise.
libgcc/
2016-07-27
Hi David,
On 30-09-2024 18:24, David Faust wrote:
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
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
Based on observation within bpf-next selftests and comparisson of GCC
and clang compile
On 30-09-2024 18:47, David Faust wrote:
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
meanin
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 being an access index for "struct A a" declaration, its
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/config/bpf/btfext-out.cc | 6
gcc/
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 convertion we will need to mark
the LHS tree nodes of gimpl
Hi everyone,
This patches series includes fixes for bugs uncovered when executing
bpf-next selftests.
Looking forward to your comments.
Regards,
Cupertino
Cupertino Miranda (3):
bpf: make sure CO-RE relocs are never typed with a BTF_KIND_CONST
bpf: calls do not promote attr access_index
Thanks! Added changelog and Pushed!
On 14-10-2024 19:08, Cupertino Miranda wrote:
On 30-09-2024 18:47, David Faust wrote:
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 reloc
Thanks! Added changelog and Pushed!
On 30-09-2024 18:39, David Faust wrote:
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
Thanks! Added changelog and Pushed!
On 15-10-2024 19:51, David Faust wrote:
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
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.
* con
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
>
> 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
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
+++ b/gcc
>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
>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
Hi everyone,
Just to confirm that I pushed the change in MAINTAINERS file, adding
myself to the write after approval list.
Thanks,
Cupertino
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: fixe
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: fi
>> 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 -
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.
Regte
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
.../bpf/core-builtin-enumvalue_opt.c
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 _
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.
>>
>> T
>> + /* 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), \
>> +gen_rtx_CONS
>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_index
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]
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
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
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
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
>>
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
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
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:
&
1 - 100 of 120 matches
Mail list logo