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

Hi, Thanks for the finding. I will fix it in next upcoming patches. Thanks, Cupertino Shung-Hsi Yu writes: > Hi, > > Thanks for working on the BPF backend! > > I noticed a tiny typo while test compiling libbpf-tools[1]. (Have yet look > into the cause of failure in detail though) > > On Thu,

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

Thanks! Pushed to master. Jose E. Marchesi writes: > Hi Cuper. > > OK. Hopefully all the roots are marked now to avoid these nodes being > collected. > > Thanks. > >> Hi everyone, >> >> This patch fixes BPF CO-RE builtins support that missed information for >> garbage collector (GC). >> >>

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

Hi everyone, This patch fixes BPF CO-RE builtins support that missed information for garbage collector (GC). The BPF CO-RE implementation defines several data structures that keep builtin information throught all of the compilation flow aside from code. This intentionally avoids having the

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

Pushed to upstream master. Thanks ! Jose E. Marchesi writes: > OK. > Thanks. > >> 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

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: Implementation of BPF CO-RE builtins >>

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] bpf:

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_index and

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

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

[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

Thanks for the suggestions/fixes in changelog. Inlined new patch. Cupertino >> gcc/ChangeLog: >> >> * config/bpf/bpf.opt: Added option -masm=. >> * config/bpf/bpf-opts.h: Likewize. >> * config/bpf/bpf.cc: Changed it to conform with new pseudoc >>dialect support. >> *

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

Hi Jose, Thanks for the review. New patch is inline attached. Regards, Cupertino Jose E. Marchesi writes: > Hello Cuper. > > Thanks for the patch. > > We will need an update for the "eBPF Options" section in the GCC manual, > documenting -masm=@var{dialect} and the supported values. Can you

[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 .global entries order is reversed

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

Thank you ! > > Best regards, > Cupertino > > > Cupertino Miranda writes: > >> PING ! >> >> Cupertino Miranda via Gcc-patches writes: >> >>> Hi Jeff, >>> >>> Can you please confirm if the patch is Ok? >>> >>>

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

ING ! > > 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

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

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

c-*-*] + || [check-flags { "" { powerpc64-*-* } { -m32 } }] } { + return 0 +} + return 1 +} Jeff Law writes: > On 12/7/22 08:45, Cupertino Miranda wrote: >> >>> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >>>> This commit is a follow

Re: [PATCH 1/2] select .rodata for const volatile variables.

Hi Jeff, Kindly calling your attention to this thread. Regards, Cupertino Cupertino Miranda via Gcc-patches writes: > Richard Biener writes: > >> On Mon, Dec 5, 2022 at 7:07 PM Jeff Law via Gcc-patches >> wrote: >>> >>> >>> >>> On

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

Cupertino Miranda writes: >> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >>> This commit is a follow up of bugzilla #107181. >>> The commit /a0aafbc/ changed the default implementation of the >>> SELECT_SECTION hook in order to match clang/llvm

Re: [PATCH 1/2] select .rodata for const volatile variables.

Richard Biener writes: > On Mon, Dec 5, 2022 at 7:07 PM Jeff Law via Gcc-patches > wrote: >> >> >> >> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >> > Changed target code to select .rodata section for 'const volatile' >> > defin

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

PING PING Cupertino Miranda writes: > Cupertino Miranda via Gcc-patches writes: > >> gentle ping >> >> Cupertino Miranda writes: >> >>>> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >>>>> This commit is a follow u

Re: [PING] Re: [PATCH 1/2] select .rodata for const volatile variables.

PING PING Cupertino Miranda writes: > Cupertino Miranda via Gcc-patches writes: > >> gentle ping >> >> Cupertino Miranda writes: >> >>> Hi Jeff, >>> >>> First of all thanks for your quick review. >>> Apologies for the delay rep

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

Cupertino Miranda via Gcc-patches writes: > gentle ping > > Cupertino Miranda writes: > >>> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >>>> This commit is a follow up of bugzilla #107181. >>>> The commit /a0aafbc/ changed the defa

[PING] Re: [PATCH 1/2] select .rodata for const volatile variables.

Cupertino Miranda via Gcc-patches writes: > gentle ping > > Cupertino Miranda writes: > >> Hi Jeff, >> >> First of all thanks for your quick review. >> Apologies for the delay replying, the message got lost in my inbox. >> >>> On 12/

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

gentle ping Cupertino Miranda writes: >> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >>> This commit is a follow up of bugzilla #107181. >>> The commit /a0aafbc/ changed the default implementation of the >>> SELECT_SECTION hook in order to

Re: [PATCH 1/2] select .rodata for const volatile variables.

gentle ping Cupertino Miranda writes: > Hi Jeff, > > First of all thanks for your quick review. > Apologies for the delay replying, the message got lost in my inbox. > >> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >>> Changed target code to sel

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

> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >> This commit is a follow up of bugzilla #107181. >> The commit /a0aafbc/ changed the default implementation of the >> SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the >> placement

Re: [PATCH 1/2] select .rodata for const volatile variables.

Hi Jeff, First of all thanks for your quick review. Apologies for the delay replying, the message got lost in my inbox. > On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >> Changed target code to select .rodata section for 'const volatile' >> defined variables.

[PATCH 1/2] select .rodata for const volatile variables.

Changed target code to select .rodata section for 'const volatile' defined variables. This change is in the context of the bugzilla #170181. gcc/ChangeLog: v850.c(v850_select_section): Changed function. --- gcc/config/v850/v850.cc | 1 - 1 file changed, 1 deletion(-) diff --git

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

This commit is a follow up of bugzilla #107181. The commit /a0aafbc/ changed the default implementation of the SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the placement of `const volatile' objects. However, the following targets use target-specific selection functions and

[PATCH] `const volatile' sections selection - bugzilla #107181

Hi everyone, Recently I looked over the issue reported in bugzilla #107181, related to commit `a0aafbc'. The commit changes the object section for `const volatile' objects. However it does it only for the targets using the default section selection hook. The included patches addresses all the