[Bug target/104656] [12 Regression] trunk 20220222 ftbfs for bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104656 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #5 from Jose E. Marchesi --- Yes that would require changing the kernel ABI. Also, there is the kernel verifier to deal with: stack accesses are tracked at load-time and they should be done using certain registers and following certain rules. For the time being, --disabling-gcov when building for BPF seems like a reasonable thing to do. Will write and send a patch in that effect.
[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 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #1 from Jose E. Marchesi --- Hello. Thanks for reporting this. Could you please attach the $top_builddir/gcc/testsuite/gcc/gcc.log file you get after running the testsuite? Thanks.
[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 #2 from Jose E. Marchesi --- Don't bother I just reproduced the issue in powerpc64le-linux-gnu.
[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 #3 from Jose E. Marchesi --- This is due to having not so good regular expressions in the test btf-int-1.c and to a slightly different way than the powerpc backend has to comment lines in assembly. Working on a fix.
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 --- Comment #9 from Jose E. Marchesi --- So I got feedback from the clang/llvm folks on this. As you can see in [1] they asked the WG14 reflectors about the footnote 135 in the C18 spec and their conclusion is that there is no normative objection to place `const volatile' variables in read-only sections, much like non-volatile consts. This matches my earlier impression (before I got pointed to that footnote) and since there is at least one target being impacted by this GCC/LLVM discrepancy (bpf-unknown-none) I intend to prepare a patch to change the place where GCC places the `const volatiles'. [1] https://github.com/llvm/llvm-project/issues/56468
[Bug c/106537] New: GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
Bug ID: 106537
Summary: GCC doesn't support
-W[no-]compare-distinct-pointer-types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
GCC emits pedwarns unconditionally when comparing pointers of different types,
for example:
int xdp_context (struct xdp_md *xdp)
{
void *data = (void *)(long)xdp->data;
__u32 *metadata = (void *)(long)xdp->data_meta;
__u32 ret;
if (metadata + 1 > data)
return 0;
return 1;
}
/home/jemarch/foo.c: In function ‘xdp_context’:
/home/jemarch/foo.c:15:20: warning: comparison of distinct pointer types
lacks a cast
15 | if (metadata + 1 > data)
|^
LLVM supports an option -W[no-]compare-distinct-pointer-types that can be used
in order to enable or disable the emission of such warnings. It is enabled by
default.
This option is used in the kernel source tree for some BPF programs.
I already got a patch for this.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 --- Comment #2 from Jose E. Marchesi --- (In reply to Andrew Pinski from comment #1) > > This option is used in the kernel source tree for some BPF programs. > > Why not fix the sources? Seems not hard to add a cast or two. That's what I would recommend. But since LLVM supports that switch it becomes difficult to convince people to not use it in case they are already using it. Sent a proposal patch in: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599393.html
[Bug target/106733] New: bpf: facilitate constant propagation of function addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
Bug ID: 106733
Summary: bpf: facilitate constant propagation of function
addresses
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
eBPF effectively supports two kind of call instructions:
- The so called pseudo-calls ("bpf to bpf").
- External calls ("bpf to kernel").
The BPF call instruction always gets an immediate argument, whose
interpretation varies depending on the purpose of the instruction:
- For pseudo-calls, the immediate argument is interpreted as a
32-bit PC-relative displacement measured in number of 64-bit words
minus one.
- For external calls, the immediate argument is interpreted as the
identification of a kernel helper.
In order to differenciate both flavors of CALL instructions the SRC
field of the instruction (otherwise unused) is abused as an opcode;
if the field holds 0 the instruction is an external call, if it holds
BPF_PSEUDO_CALL the instruction is a pseudo-call.
C-to-BPF toolchains, including the GNU toolchain, use the following
practical heuristic at assembly time in order to determine what kind
of CALL instruction to generate: call instructions requiring a fixup
at assembly time are interpreted as pseudo-calls. This means that in
practice a call instruction involving symbols at assembly time (such
as `call foo') is assembled into a pseudo-call instruction, whereas
something like `call 12' is assembled into an external call
instruction.
In both cases, the argument of CALL is an immediate: at the time of
writing eBPF lacks support for indirect calls, i.e. there is no
call-to-register instruction.
This is the reason why BPF programs, in practice, rely on certain
optimizations to happen in order to generate calls to immediates.
This is a typical example involving a kernel helper:
static void * (*bpf_map_lookup_elem)(void *map, const void *key
= (void *) 1;
int foo (...)
{
char *ret;
ret = bpf_map_lookup_elem (args...);
if (ret)
return 1;
return 0;
}
Note how the code above relies on the compiler to do constant
propagation so the call to bpf_map_lookup_elem can be compiled to a
`call 1' instruction.
While GCC provides a kernel_helper function declaration attribute that
can be used in a robust way to tell GCC to generate an external call
despite of optimization level and any other consideration, the Linux
kernel bpf_helpers.h file relies on tricks like the above.
The BPF backend is currently causing the expander to "undo" SSA constant
propagations like the above by loading function addresses into registers. This
makes code like the above to not compile properly even with optimization levels
of O2 or more.
[Bug target/106733] bpf: facilitate constant propagation of function addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733 --- Comment #2 from Jose E. Marchesi --- Urgh I obviously meant bpf-unknown-none.
[Bug target/106733] bpf: facilitate constant propagation of function addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733 Jose E. Marchesi changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jose E. Marchesi --- Changing status to fixed.
[Bug testsuite/107181] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #2 from Jose E. Marchesi --- Looking at it...
[Bug target/107438] New: bpf:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107438 Bug ID: 107438 Summary: bpf: Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jose.marchesi at oracle dot com Target Milestone: --- We noticed that recently LLVM changed the BPF ABI by allowing to pass small record arguments by value. Previously all records were passed by reference. This is the LLVM change: https://reviews.llvm.org/D132144 The GCC backend should be adapted to follow the same ABI.
[Bug target/107848] libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 --- Comment #2 from Jose E. Marchesi --- This is likely due to the fact they added new BPF relocations: https://reviews.llvm.org/D102712 Or course not bothering telling us.
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #6 from Jose E. Marchesi --- So I am being bitten by this in the BPF backend [1]. Long story short: LLVM places initialized `volatile const' variables in .rodata, whereas GCC puts them in .data. The kernel's libbpf scans the objects and generates a "skeleton" header that, among other things, reflects the sections in the compiled BPF object. This divergence in behavior between LLVM and GCC makes the skeleton to define different data structures, i.e. obj->rodata->foo vs. obj->data->foo. See [1] for details. I don't actually understand Gabriel's comment, "If it may be modified by hardware or other external means, it can't go into .rodata section.". Why not? The permissions of the .rodata section eventually determines the permissions used to map the corresponding pages in the particular process running the program, but I don't see how can prevent the same physical memory to be updated by hardware, or even other processes mapping the same physical page using write perms. Or what am I missing? Can we change the behavior of GCC to put such variables in .rodata? [1] https://lore.kernel.org/bpf/87fsj8vjcy@oracle.com/T/#me726127e166f97fd50f09b647a604f176f809c63
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
--- Comment #7 from Jose E. Marchesi ---
If, as a workaround, I try to use a `section' attribute, like in:
__attribute__((section(".rodata"))) volatile const int lala = 0;
I don't get an ICE, but a section with write permissions:
.section.rodata,"aw"
And the assembler then complains:
foo-gcc.s:4: Warning: setting incorrect section attributes for .rodata
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 --- Comment #8 from Jose E. Marchesi --- After a little discussion in IRC I filed this LLVM bug: https://github.com/llvm/llvm-project/issues/56468 Regarding the ICE described by Ulrich, I cannot reproduce it using: bpf-unknown-none-gcc (GCC) 13.0.0 20220708 (experimental) Maybe it is time to close this bug?
[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270 --- Comment #3 from Jose E. Marchesi --- Wilco: The assessment in comment 1 was extracted from an internal discussion on an issue that is still under investigation. We are certainly hitting a cant-reach-the-linker-generated-veneer problem, but it is not fully clear to us how since it is getting difficult to get proper reproducers. In any case, the idea of splitting of the text section by the compiler is interesting, and a much better solution than -mlong-calls since it wouldn't involve generate unnecessary indirect branches. But how would the back-end keep track on the size of the code it generates? Using insn size attributes?
