[Bug target/107843] error: incompatible type for argument in ___bpf_ctx_cast2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107843 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jose E. Marchesi --- clang/llvm confirms that clang 15 behaves like GCC, emitting the same error. So I am closing this issue.
[Bug target/108293] Incorrect assembly emitted for float for BPF target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293 Jose E. Marchesi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jose E. Marchesi --- Fixed.
[Bug testsuite/106515] [13 regression] gcc.dg/debug/btf/btf-int-1.c fails after r13-1937-g5df04a7aa837a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515 --- Comment #6 from Jose E. Marchesi --- (In reply to Richard Biener from comment #5) > Fixed I assume. Yes indeed. Sorry about leaving all these bugs in the "open" state. Only recently I managed to get my bugzilla accounts consolidated in a @gcc.gnu.org one, so I can have editbugs.
[Bug target/108293] Incorrect assembly emitted for float for BPF target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293 --- Comment #3 from Jose E. Marchesi --- (In reply to Jakub Jelinek from comment #2) > Another thing is that at least for all SFmode constant one could use mov > instead of lddw. For this I guess we could expand the "I" constraint to cover const_double that fits in the 32-bit range. But then we would need something like IN_RANGE that works with const_double.
[Bug target/106745] segfault in bpf_core_get_sou_member_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106745 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jose E. Marchesi --- This is fixed.
[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #20 from Jose E. Marchesi --- This is fixed.
[Bug target/107843] error: incompatible type for argument in ___bpf_ctx_cast2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107843 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-06 Ever confirmed|0 |1 --- Comment #2 from Jose E. Marchesi --- Opened a clang/llvm bug for this, to see if they would consider turning the warning into an error to converge with GCC's behavior. https://github.com/llvm/llvm-project/issues/59858
[Bug c/113825] New: missing warning for omitted parameter names in function definitions (c23 extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113825
Bug ID: 113825
Summary: missing warning for omitted parameter names in
function definitions (c23 extension)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jemarch at gcc dot gnu.org
Target Milestone: ---
Given this code:
struct bpf_iter_num;
static inline int bpf_iter_num_next(struct bpf_iter_num *) { return 1; }
Clang gives us this warning:
clang -target x86_64 -c foo.c
foo.c:2:58: warning: omitting the parameter name in a function definition is a
C23 extension [-Wc23-extensions]
2 | static inline int bpf_iter_num_next(struct bpf_iter_num *) { return 1;
}
| ^
1 warning generated.
However, GCC doesn't emit any warning even when it is explicitly invoked with
-std=gnu89 or -std=c99.
Shall we emit warnings for this and other C23 extensions when not building with
std=c23?
[Bug target/114431] New: bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 Bug ID: 114431 Summary: bpf: GCC generates unverifiable code for systemd restrict_fs_bpf Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- GCC generates unverifiable code for systemd restrict_fs_bpf and the kernel verifier complains with the error log below. The corresponding systemd issue is https://github.com/systemd/systemd/issues/31888. Mär 21 11:01:44 H systemd[1]: bpf-firewall: Got EBADF when using BPF_F_ALLOW_MULTI, which indicates it is supported. Yay! Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping section(3) .data (size 0) Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping unrecognized data section(9) .comment Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_bind4': failed to attach to cgroup: Bad file descriptor Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping section(3) .data (size 0) Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping unrecognized data section(10) .comment Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_restrictif_e': BPF program load failed: Permission denied Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_restrictif_e': -- BEGIN PROG LOAD LOG -- Mär 21 11:01:44 H systemd[1]: 0: R1=ctx(off=0,imm=0) R10=fp0 Mär 21 11:01:44 H systemd[1]: 0: (61) r0 = *(u32 *)(r1 +40) ; R0_w=scalar(smin=0,smax=umax=4294967295,var_off=(0x0; 0x)) R1=ctx(off=0,imm=0) Mär 21 11:01:44 H systemd[1]: 1: (bf) r2 = r10 ; R2_w=fp0 R10=fp0 Mär 21 11:01:44 H systemd[1]: 2: (18) r1 = 0x992d011eec00 ; R1_w=map_ptr(off=0,ks=4,vs=1,imm=0) Mär 21 11:01:44 H systemd[1]: 4: (07) r2 += -4 ; R2_w=fp-4 Mär 21 11:01:44 H systemd[1]: 5: (63) *(u32 *)(r10 -4) = r0 ; R0_w=scalar(smin=0,smax=umax=4294967295,var_off=(0x0; 0x)) R10=fp0 fp-8= Mär 21 11:01:44 H systemd[1]: 6: (85) call bpf_map_lookup_elem#1; R0_w=map_value_or_null(id=1,off=0,ks=4,vs=1,imm=0) Mär 21 11:01:44 H systemd[1]: 7: (18) r1 = 0xbf18005c2000 ; R1_w=map_value(off=0,ks=4,vs=1,imm=0) Mär 21 11:01:44 H systemd[1]: 9: (69) r3 = *(u16 *)(r1 +0) Mär 21 11:01:44 H systemd[1]: invalid access to map value, value_size=1 off=0 size=2 Mär 21 11:01:44 H systemd[1]: R1 min value is outside of the allowed memory range Mär 21 11:01:44 H systemd[1]: processed 8 insns (limit 100) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 Mär 21 11:01:44 H systemd[1]: -- END PROG LOAD LOG -- Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_restrictif_e': failed to load: -13 Mär 21 11:01:44 H systemd[1]: libbpf: failed to load object 'restrict_ifaces_bpf' Mär 21 11:01:44 H systemd[1]: libbpf: failed to load BPF skeleton 'restrict_ifaces_bpf': -13 Mär 21 11:01:44 H systemd[1]: restrict-interfaces: Failed to load BPF object: Permission denied Mär 21 11:01:44 H systemd[1]: restrict-interfaces: Failed to load BPF object: Permission denied Mär 21 11:01:44 H systemd[1]: Controller 'cpu' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'cpuacct' supported: no Mär 21 11:01:44 H systemd[1]: Controller 'cpuset' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'io' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'blkio' supported: no Mär 21 11:01:44 H systemd[1]: Controller 'memory' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'devices' supported: no Mär 21 11:01:44 H systemd[1]: Controller 'pids' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-firewall' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-devices' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-foreign' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-socket-bind' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-restrict-network-interfaces' supported: no Mär 21 11:01:44 H systemd[1]: Set up TFD_TIMER_CANCEL_ON_SET timerfd. Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping section(3) .data (size 0) Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping unrecognized data section(8) .comment Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': missing .BTF.ext function info for the main program, skipping all of .BTF.ext func info. Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': missing .BTF.ext line info for the main program, skipping all of .BTF.ext line info. Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': BPF program load failed: Permission denied Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': -- BEGIN PROG LOAD LOG -- Mär 21 11:01:44 H systemd[1]: 0: R1=ctx(off=0,imm=0) R10=fp0 Mär 21 11:01:44 H systemd[1]: 0: (62) *(u32 *)(r10 -20) = 0 ; R10=fp0 fp-24= Mär 21 11:01:44 H systemd[1]: 1: (bf) r0 = r1
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #1 from Jose E. Marchesi --- $ bpf-gcc --version bpf-gcc (14-20240127-1+1) 14.0.1 20240127 (experimental) [master r14-8465-g5200ef26ac1] Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #2 from Jose E. Marchesi --- Created attachment 57795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57795&action=edit socket-bind.bpf.unstripped.i preprocessed source
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #3 from Jose E. Marchesi --- Created attachment 57796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57796&action=edit restrict-ifaces.bpf.unstripped.i
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 --- Comment #4 from Jose E. Marchesi --- Created attachment 57797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57797&action=edit restrict-fs-.bpf.unstripped.i
[Bug target/114523] bpf: ssa-phiopt optimization generates unverifiable code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 Jose E. Marchesi changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|NEW Resolution|INVALID |--- CC||jemarch at gcc dot gnu.org Last reconfirmed||2024-03-28 --- Comment #9 from Jose E. Marchesi --- Please do not close this bug. We are well aware this is a limitation in the kernel verifier, but we need to keep track of this. In general, like in this case, many of the problems related to unverifiable generated code can be reduced to "this is a kernel verifier bug, make it smarter", but that doesn't mean we can't put workarounds in the back-end so we can actually compile actually-existing BPF programs (such as that systemd utility) in actually-existing current kernels. That includes disabling certain optimizations. I don't like it any more than you do, trust me on that. Note that the development of the BPF backends, in both clang and GCC, are by necessity very much in lock-step with the kernel BPF support. So this is not something we will forget to "undo" as soon as the verifier can handle these instructions. Very likely we will be doing the kernel patch as well.
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 Bug 114431 depends on bug 114523, which changed state. Bug 114523 Summary: bpf: ssa-phiopt optimization generates unverifiable code. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |---
[Bug target/114523] bpf: unverifable code due to subreg usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523 --- Comment #13 from Jose E. Marchesi --- Thanks. The new title is way better. And thank you for the further analysis and the reproducer that also makes clang to generate the no-verifiable code! I wonder, is the issue also there when -mno-alu32 is used? In that case the generated code doesn't involve "subregs" (or 32-bit operations in assembly-like syntax): .file "foo.c" .text .align 3 .global foo .type foo, @function foo: callbar lddw%r1,baz mov %r0,%r0 and %r0,0x ldxw%r2,[%r1+0] add %r0,-1 neg %r2 xor %r0,%r2 rsh %r0,63 exit .size foo, .-foo .global baz .type baz, @object .lcomm baz,4,4 .ident "GCC: (GNU) 14.0.1 20240226 (experimental)" Cuper, is the verifier able to track proper values through the xor in this case?
[Bug target/110781] New: bpf: make use of the V4 long-range jump instruction (jal/gotol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110781 Bug ID: 110781 Summary: bpf: make use of the V4 long-range jump instruction (jal/gotol) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- The BPF V4 ISA introduces a new unconditional jump instruction (jal/gotol) that has a much wide target range compared to the previous jal/goto instruction: from PC-relative 16-bit to PC-relative 32-bit. We shall make GCC to generate this instruction when it needs to emit jumps that would be too long for the regular ja/goto instruction. But only if -mcpu=v4 is used.
[Bug target/110782] New: bpf: make use of the V4 sign-extended load instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110782 Bug ID: 110782 Summary: bpf: make use of the V4 sign-extended load instructions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- The BPF V4 ISA introduces sign-extended load instructions, to load 8-bit, 16-bit, 32-bit and 64-bit values from memory to a 64-bit register with sign extension. We should make GCC use these instructions whenever feasible/desirable.
[Bug target/110783] New: bpf; make sure of V4 signed division/modulus instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110783 Bug ID: 110783 Summary: bpf; make sure of V4 signed division/modulus instructions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- The BPF V4 ISA introduces support for signed division and signed modulus instructions. Up to now, we were supporting these instructions in GCC only for -mxbpf. We shall change the compiler in order to generate them with -mcpu=v4 or later instead.
[Bug target/110784] New: bpf: make use of the V4 sign-extended move instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110784 Bug ID: 110784 Summary: bpf: make use of the V4 sign-extended move instructions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- The BPF V4 ISA introduces three new instructions to move 16-, 32- and 64-bit signed values to 64-bit registers with sign extension. We shall make GCC to use these instructions whenever feasible/desirable, but only with -mcpu=v4 or later.
[Bug target/110786] New: bpf: make use of the V4 byte swap instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110786
Bug ID: 110786
Summary: bpf: make use of the V4 byte swap instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jemarch at gcc dot gnu.org
Target Milestone: ---
The BPF V4 ISA introduces support for byte-swap instructions: bswap16, bswap32
and bswap64. GCC shall be adapted to use these instructions for the builtins:
__builtin_bswap{16,32,64}
[Bug target/110786] bpf: make use of the V4 byte swap instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110786 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jemarch at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-07-24
[Bug target/110786] bpf: make use of the V4 byte swap instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110786 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jose E. Marchesi --- GCC updated.
[Bug target/110783] bpf; make sure of V4 signed division/modulus instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110783 Jose E. Marchesi changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jemarch at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-07-24
[Bug target/110783] bpf; make sure of V4 signed division/modulus instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110783 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed in git master.
[Bug target/110781] bpf: make use of the V4 long-range jump instruction (jal/gotol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110781 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jose E. Marchesi --- This is actually the assembler's business. Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=30690
[Bug target/109068] bpf: "error: too many function arguments for eBPF" for always_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068 Jose E. Marchesi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by: commit 6103df1e4fae5192c507484b1d32f00c42c70b54 Author: Jose E. Marchesi Date: Thu Aug 10 10:53:16 2023 +0200 bpf: allow exceeding max num of args in BPF when always_inline BPF currently limits the number of registers used to pass arguments to functions to five registers. There is a check for this at function expansion time. However, if a function is guaranteed to be always inlined (and its body never generated) by virtue of the always_inline attribute, it can "receive" any number of arguments.
[Bug target/111029] New: bpf: GCC generates invalid instructions wN = (s8) rM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111029 Bug ID: 111029 Summary: bpf: GCC generates invalid instructions wN = (s8) rM Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- Created attachment 55738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55738&action=edit preprocessed source of kernel bpf selftest When compiling the attached pre-processed program (which is a kernel bpf selftest) with gcc-bpf we get invalid pseudo-c movs32 instructions: $ bpf-unknown-none-gcc -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian -O2 -gbtf -masm=pseudoc -mco-re -Wno-unknown-pragmas -Wno-unused-variable -Wno-error=attributes -Wno-error=address-of-packed-member -c test_sysctl_prog.i /tmp/ccgPxp1s.s: Assembler messages: /tmp/ccgPxp1s.s:63: Error: unrecognized instruction `w2 =(s8)r1' /tmp/ccgPxp1s.s:63: Error: expected register name, got 'r1' /tmp/ccgPxp1s.s:71: Error: unrecognized instruction `w4 =(s8)r3' /tmp/ccgPxp1s.s:71: Error: expected register name, got 'r3' /tmp/ccgPxp1s.s:79: Error: unrecognized instruction `w9 =(s8)r5' /tmp/ccgPxp1s.s:79: Error: expected register name, got 'r5' /tmp/ccgPxp1s.s:88: Error: unrecognized instruction `w1 =(s8)r0' /tmp/ccgPxp1s.s:88: Error: expected register name, got 'r0' /tmp/ccgPxp1s.s:96: Error: unrecognized instruction `w3 =(s8)r2' /tmp/ccgPxp1s.s:96: Error: expected register name, got 'r2' /tmp/ccgPxp1s.s:104: Error: unrecognized instruction `w5 =(s8)r4' /tmp/ccgPxp1s.s:104: Error: expected register name, got 'r4' /tmp/ccgPxp1s.s:112: Error: unrecognized instruction `w0 =(s8)r9' /tmp/ccgPxp1s.s:112: Error: expected register name, got 'r9' /tmp/ccgPxp1s.s:120: Error: unrecognized instruction `w2 =(s8)r1' /tmp/ccgPxp1s.s:120: Error: expected register name, got 'r1' /tmp/ccgPxp1s.s:128: Error: unrecognized instruction `w4 =(s8)r3' /tmp/ccgPxp1s.s:128: Error: expected register name, got 'r3' /tmp/ccgPxp1s.s:136: Error: unrecognized instruction `w9 =(s8)r5' /tmp/ccgPxp1s.s:136: Error: expected register name, got 'r5' /tmp/ccgPxp1s.s:144: Error: unrecognized instruction `w1 =(s8)r0' /tmp/ccgPxp1s.s:144: Error: expected register name, got 'r0' /tmp/ccgPxp1s.s:152: Error: unrecognized instruction `w3 =(s8)r2' /tmp/ccgPxp1s.s:152: Error: expected register name, got 'r2' /tmp/ccgPxp1s.s:160: Error: unrecognized instruction `w5 =(s8)r4' /tmp/ccgPxp1s.s:160: Error: expected register name, got 'r4' /tmp/ccgPxp1s.s:168: Error: unrecognized instruction `w0 =(s8)r9' /tmp/ccgPxp1s.s:168: Error: expected register name, got 'r9' /tmp/ccgPxp1s.s:176: Error: unrecognized instruction `w2 =(s8)r1' /tmp/ccgPxp1s.s:176: Error: expected register name, got 'r1' /tmp/ccgPxp1s.s:184: Error: unrecognized instruction `w4 =(s8)r3' /tmp/ccgPxp1s.s:184: Error: expected register name, got 'r3' /tmp/ccgPxp1s.s:192: Error: unrecognized instruction `w9 =(s8)r5' /tmp/ccgPxp1s.s:192: Error: expected register name, got 'r5'
[Bug target/111046] New: bpf: support naked functions in BPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111046 Bug ID: 111046 Summary: bpf: support naked functions in BPF Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- BPF programs make use of the `naked' function attribute. This attribute is supported by several targets in GCC but not currently by bpf targets.
[Bug target/111046] bpf: support naked functions in BPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111046 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jose E. Marchesi --- Fixed with the above commit.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jose E. Marchesi --- Fixed in the commit above.
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 106537, which changed state. Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/111029] bpf: GCC generates invalid instructions wN = (s8) rM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111029 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/110770] bpf: add pseudoc assembly dialect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by commit above.
[Bug target/110784] bpf: make use of the V4 sign-extended move instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110784 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/110782] bpf: make use of the V4 sign-extended load instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110782 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/108790] bpf: gcc emits malformed ldxdw instruction at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108790 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||jemarch at gcc dot gnu.org --- Comment #2 from Jose E. Marchesi --- Fixed by the commit above.
[Bug tree-optimization/48783] ~0ULL % (a / (a & -a)) == 0 is not optimized to false on the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org --- Comment #9 from Jose E. Marchesi --- Note https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627864.html
[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109253 --- Comment #2 from Jose E. Marchesi --- A patch to fix this was sent https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627864.html
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Jose E. Marchesi changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Last reconfirmed||2023-08-24 Resolution|FIXED |--- --- Comment #8 from Jose E. Marchesi --- I am on it.
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 106537, which changed state. Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug debug/116663] [14/15 regression] CTF array dimensions dumped backwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116663 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jose E. Marchesi --- Resolving as invalid since this should be filed in binutils.
[Bug target/116717] New: bpf: fix built-in functions for memory model aware atomic operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116717 Bug ID: 116717 Summary: bpf: fix built-in functions for memory model aware atomic operations. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- Target: bpf At the moment the BPF target ignores the memory ordering arguments passed to atomic builtins, generating code that always implements monotonic ordering. We should change the target to emit instructions for the two ordering schemas supported by BPF: total and relaxed. __ATOMIC_RELAXED lock* instruction if result is not used, atomic_fetch_OP if it is used. __ATOMIC_CONSUME __ATOMIC_ACQUIRE __ATOMIC_RELEASE __ATOMIC_ACQ_REL __ATOMIC_SEQ_CST BPF: atomic_fetch_OP instructions. Note this is WIP in clang as well, with corresponding LLVM PR: https://github.com/llvm/llvm-project/pull/107343
[Bug target/116718] New: bpf: support bpf_fastcall attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116718 Bug ID: 116718 Summary: bpf: support bpf_fastcall attributes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- Target: bpf BPF is introducing a way to perform load-time optimizations by inlining function calls to instruction sequences. Calls to functions marked with the bpf_fastcall attributes should not clobber caller-preserved registers so they not alter register pressure in their containing units. Instead, the compiler shall generate certain fixed patterns to save and restore argument and result registers, which are then recognized by the BPF verifier and patched. Corresponding clang/llvm PR: https://github.com/llvm/llvm-project/pull/101228
[Bug target/116718] bpf: support bpf_fastcall attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116718 --- Comment #2 from Jose E. Marchesi --- As far as I can tell the feature requires no inlining to happen. From the llvm patch: After this patch-set verifier would rewrite the program below: r2 = 1 *(u64 *)(r10 - 32) = r2 call %[bpf_cast_to_kern_ctx] r2 = *(u64 *)(r10 - 32) r0 = r2;" As follows: r2 = 1 /* spill/fill at r10[-32] is removed */ r0 = r1 /* replacement for bpf_cast_to_kern_ctx() */ r0 = r2 exit i.e. the call to bpf_cast_to_kern_ctx is not inlined, but shouldn't impact register presure like if it was marked with nocsr. The argument and return value handling instructions are generated ad-hoc for the call, and in a shape that is recognized by the BPF loader. Then the BPF loader replaces the call with something else. It is akin to inlining at load time, which may or may not happen depending on the version of the kernel.
[Bug target/107848] libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jose E. Marchesi --- This was due to a binutils bug. Fixed by the following binutils upstream commits: commit 5f784ec9277e9303eee3ce366c40ce9fa3203f3e Author: Cupertino Miranda Date: Fri Mar 17 15:29:36 2023 + Changed ld and gas BPF tests Recent BPF patch removed and renamed the list of relocations based on the limitations of BPF instruction set. This patch is a correction to the tests. commit 551fde0ae1691a74e1fdfb2bd33e8453106c0c87 Author: Cupertino Miranda Date: Fri Mar 17 15:27:02 2023 + Reloc howto access broken for BPF Forgot to change the logic to access the reloc howto from bpf_elf_relocate_section. Problem was introduced in previous BPF commit. commit 5e4c7a839d1c0d68a4a518cf2dc8e87925575e58 Author: Cupertino Miranda Date: Thu Mar 16 08:39:52 2023 + BPF relocations review / refactoring - Removed not needed relocations. - Renamed relocations to match llvm and linux kernel. Relocation changes: R_BPF_INSN_64 => R_BPF_64_64 R_BPF_INSN_DISP32 => R_BPF_64_32 R_BPF_DATA_32 => R_BPF_64_ABS32 R_BPF_DATA_64 => R_BPF_64_ABS64
[Bug target/109558] New: bpf: support BTF and DWARF tag annotations for BPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558 Bug ID: 109558 Summary: bpf: support BTF and DWARF tag annotations for BPF Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- There is a need to support: - Two new C-language-level attributes that allow to associate (to "tag") particular declarations and types with arbitrary strings. This is intended to be used to, for example, characterize certain pointer types in the kernel verifier. - The conveyance of that information in the DWARF output in the form of a new DIE: DW_TAG_(GNU|LLVM)_annotation. - The conveyance of that information in the BTF output in the form of two new kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG. All of these facilities are being added to the eBPF ecosystem, and support for them exists in some form in LLVM. We have already discussed and agred on the details of what to support.
[Bug target/109558] bpf: support BTF and DWARF tag annotations for BPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2023-04-19 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |david.faust at oracle dot com Ever confirmed|0 |1
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 Jose E. Marchesi changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |cupertino.miranda at oracle dot co ||m
[Bug target/107481] bpf: add __builtin_preserve_enum_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107481 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org Last reconfirmed||2023-04-19 Assignee|unassigned at gcc dot gnu.org |cupertino.miranda at oracle dot co ||m Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug target/107480] bpf: add __builtin_preserve_type_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107480 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2023-04-19 Assignee|unassigned at gcc dot gnu.org |cupertino.miranda at oracle dot co ||m Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||jemarch at gcc dot gnu.org
[Bug target/107479] bpf: add __builtin_btf_type_id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107479 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-04-19 Assignee|unassigned at gcc dot gnu.org |cupertino.miranda at oracle dot co ||m CC||jemarch at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #13 from Jose E. Marchesi --- In bpf-next we are passing -Wno-error for the particular BPF selftests that use this construct: progs/btf_dump_test_case_bitfields.c-CFLAGS := -Wno-error progs/btf_dump_test_case_namespacing.c-CFLAGS := -Wno-error progs/btf_dump_test_case_packing.c-CFLAGS := -Wno-error progs/btf_dump_test_case_padding.c-CFLAGS := -Wno-error progs/btf_dump_test_case_syntax.c-CFLAGS := -Wno-error
[Bug target/107479] bpf: add __builtin_btf_type_id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107479 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- The patch above fixes this.
[Bug target/107480] bpf: add __builtin_preserve_type_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107480 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- Fixed.
[Bug target/107481] bpf: add __builtin_preserve_enum_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107481 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- fixed.
[Bug libgcc/112465] New: libgcc: aarch64: lse runtime does not work with big data segments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112465
Bug ID: 112465
Summary: libgcc: aarch64: lse runtime does not work with big
data segments
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jemarch at gcc dot gnu.org
Target Milestone: ---
While compiling and linking the STREAM benchmark
(http://www.cs.virginia.edu/stream/ref.html) in aarch64 with very big arrays,
this happens:
$ gcc -O2 -DSTREAM_ARRAY_SIZE=178956970 -mcmodel=large -fopenmp -o stream.4gb
stream.c
libgcc.a(lse-init.o): in function `init_have_lse_atomics':
(.text.startup+0x14): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
against `.bss'
libgcc.a(ldadd_4_1.o): in function `__aarch64_ldadd4_relax':
(.text+0x4): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
against symbol `__aarch64_have_lse_atomics' defined in .bss section in
collect2: error: ld returned 1 exit status
The LSE machinery in libgcc relies on the fact that the global
__aarch64_have_lse_atomics is reachable within 4GiB. This is due to
code like this:
.macroJUMP_IF_NOT_LSE label
adrpx(tmp0), __aarch64_have_lse_atomics
ldrbw(tmp0), [x(tmp0), :lo12:__aarch64_have_lse_atomics]
cbz w(tmp0), \label
.endm
That is put in the prologue in all LSE instructions in libcc (such as
__aarch64_ldadd4_relax in the little reproducer below) and in the
initialization routine also part of libgcc:
static void __attribute__((constructor (90)))
init_have_lse_atomics (void)
{
unsigned long hwcap = __getauxval (AT_HWCAP);
__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
}
The code compiled for the last assignment in that function also makes use of an
instruction sequence using adrp. The addressing mode implemented by adrp+ldrb
allows to access +-4GiB.
In the stream.c benchmark, and also in this little reproducer:
static int foo;
static double a[178956970],b[178956970],c[178956970];
int main ()
{
#pragma omp atomic
foo++;
return foo + a[0] + b[0] + c[0];
}
The variables a, b and c get allocated as bss. Now, it happens that
__aarch64_have_lse_atomics also goes to the bss:
/* Define the symbol gating the LSE implementations. */
_Bool __aarch64_have_lse_atomics
__attribute__((visibility("hidden"), nocommon));
But _after_ a, b and c. So it is the offset of
__aarch64_have_lse_atomics within the bss that is overflowing the
relocation for the adrp instruction.
[Bug target/112654] bpf: bpf program load failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654 --- Comment #3 from Jose E. Marchesi --- The instruction failing validation seems to be: e0: bf a4 00 00 00 00 00 00 mov %r4,%r10 Which is a regular MOV instruction with zeroes in imm32 and offset16. It has SRC=X. So I don't understand why the verifier is rejecting that instruction...
[Bug target/112654] bpf: bpf program load failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112654 --- Comment #4 from Jose E. Marchesi --- I think the problem here may be that OP's kernel doesn't understand BPF V4 instructions, and the program above has been compiled with them (movs). Try to use -mcpu=v3?
[Bug debug/112656] New: btf: function prototypes generated with name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656 Bug ID: 112656 Summary: btf: function prototypes generated with name Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- BTF suports both BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO tags. FUNC entries link to their corresponding PROTO via type_id. PROTO entries must have no names, i.e. name_off shall be 0. GCC seems to be generating non-anonymous BTF_KIND_FUNC_PROTO entries in some circumstances: $ bpf-unknown-none-gcc -c -O2 repro.i -o repro.o $ bpftool btf dump all | grep FUNC_PROTO | grep -v anon [8319] FUNC_PROTO 'kretprobe_ieee80211_get_channel_khz' ret_type_id=7 vlen=2 [8321] FUNC_PROTO 'kprobe_ieee80211_scan_completed' ret_type_id=7 vlen=2 [8333] FUNC_PROTO 'kprobe_ieee80211_request_scan' ret_type_id=7 vlen=2 [8343] FUNC_PROTO 'kprobe_unregister_netdev' ret_type_id=7 vlen=2 [8345] FUNC_PROTO 'kprobe_register_netdev' ret_type_id=7 vlen=2 [8347] FUNC_PROTO 'kprobe_ieee80211_unregister_hw' ret_type_id=7 vlen=1 [8349] FUNC_PROTO 'kprobe_ieee80211_register_hw' ret_type_id=7 vlen=1 [8351] FUNC_PROTO 'log_event' ret_type_id=0 vlen=2
[Bug debug/112656] btf: function prototypes generated with name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #1 from Jose E. Marchesi ---
Smaller reproducer:
static void log_event(const char *event_name, void *dev_ptr)
{
}
void lala ()
{
log_event ("foobar", ((void *)0));
}
Note that the FUNC_PROTO for log_event seems to be created with a name only if
the function gets inlined:
$ bpf-unknown-none-gcc -gbtf -c -O2 foo.c -o foo.o
$ bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO 'log_event' ret_type_id=1 vlen=2
'event_name' type_id=6
'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'lala' type_id=2 linkage=global
$ bpf-unknown-none-gcc -gbtf -c -O2 -fno-inline foo.c -o foo.o
$ /usr/sbin/bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO '(anon)' ret_type_id=1 vlen=2
'event_name' type_id=6
'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'lala' type_id=2 linkage=global
[9] FUNC 'log_event' type_id=3 linkage=static
[Bug debug/112656] btf: function prototypes generated with name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656 --- Comment #2 from Jose E. Marchesi --- The btf_collect_datasec function in btf2out.cc traverses the cgraph and, for each function, transforms its CTF_K_FUNCTION into a pair of BTF_KIND_FUNC_PROTO and BTF_KIND_FUNC. But if the function is inlined I don't think the transformation is performed. Thats probably why no BTF_KIND_FUNC is generated for the function with inline enabled.
[Bug debug/112656] btf: function prototypes generated with name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656 --- Comment #3 from Jose E. Marchesi --- clang does not emit BTF FUNC nor FUNC_PROTO entries for inlined functions. So the fix is probably to not emit CTF_K_FUNCTION entries that have not been handled in the FOR_EACH_FUNCTION loop.
[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jose E. Marchesi --- This is fixed by the commit above.
[Bug debug/112656] btf: function prototypes generated with name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656 Jose E. Marchesi changed: What|Removed |Added CC||david.faust at oracle dot com --- Comment #6 from Jose E. Marchesi --- Doesn't this mean that we have to split the BTF generation in two parts? First, at early_finish(), then again at finish() if -mco-re is used?
[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109253 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jose E. Marchesi --- Fixed by the commit above.
[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109253 --- Comment #6 from Jose E. Marchesi --- (In reply to Shung-Hsi Yu from comment #5) > any chance we will also have this fix in GCC 13? Yes. We plan to backport this and many other BPF related fixes and improvements to GCC 10, 11, 12 and 13, once the port is capable of building all the kernel BPF selftests. We are almost there.
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jemarch at gcc dot gnu.org --- Comment #1 from Jose E. Marchesi --- Can you please provide a pre-processed version of the reproducer? Thanks.
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2023-07-13 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jose E. Marchesi --- Thanks. Confirmed with master bpf-unknown-gcc: stxb[%fp+-20],%r7 ldxw%r7,[%fp+-20]
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #4 from Jose E. Marchesi --- Looks like `combine' is generating paradoxical subregs of mems, which seem to confuse LRA and these weird incorrect reloads end up being generated. The easiest fix for this is to make the backend to use the instruction scheduler, which makes `combine' to not generate such subregs.
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #6 from Jose E. Marchesi --- Hello Kris. The commit above (now in gcc master) should fix the issue. Can you please confirm? Thanks!
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jose E. Marchesi --- Thanks for confirming. Resolving as fixed.
[Bug debug/113000] New: Generate BTF always in early-finish regardless of CO-RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113000 Bug ID: 113000 Summary: Generate BTF always in early-finish regardless of CO-RE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- The BPF CO-RE support requires storing information relevant to the BTF debug info in the .BTF.ext section. In particular: * The CO-RE relocation strings contain references to BTF types, by type ID. * The CO-RE information includes strings that are stored in the BTF string section. Because of the above, we are generating BTF (call to ctf_debug_finish) in dwarf2out's early_finish if no -mco-re is specified, but the call is done in dwarf2out's finish instead if -mco-re is specified. This implies that there are differences in the output (also in CTF) because for example entries for inlined functions are no longer present at 'finish' time but they are at 'early_finish' time. We should change GCC so it always calls ctf_debug_finish in early_finish, regardless of whether CO-RE relocs are being generated or not.
[Bug target/113225] bpf: attribute((kernel_helper)) adds inconsistent BTF extern function decl entry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jemarch at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jose E. Marchesi --- This is fixed by the commit above.
[Bug debug/113000] Generate BTF always in early-finish regardless of CO-RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113000 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Jose E. Marchesi --- This issue got fixed using a different approach: now BTF is emitted always the same way regardless of -mco-re. Most of the BTF is computed in early_finish but emission happens always at finish. At this point the BTF may have been amended by co-re. Regarding LTO, at the moment it is not supported. That will require adding a BTF reader to GCC, or to provide BTF with enough functionality so it can be amended by adding stuff, like DWARF's abstract origin DIEs.
[Bug target/117447] ICE in BPF GCC-trunk segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117447 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2024-11-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jose E. Marchesi --- g++ is indeed not supported by the BPF back-end. It would be nice to emit a fatal error instead of a segmentation fault though.
[Bug target/118772] BPF doesn't actually support effective-target 'exceptions'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118772 --- Comment #1 from Jose E. Marchesi --- Hello Thomas. I can confirm it is ok to get check_effective_target_exceptions to return 0 for bpf-*-* targets. Thanks!
