https://bugzilla.suse.com/show_bug.cgi?id=1231247 https://bugzilla.suse.com/show_bug.cgi?id=1231247#c10 --- Comment #10 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Shung-Hsi Yu from comment #5)
The compilation error is coming from Clang/LLVM, maybe @Aaron has some clues regarding Clang's support of machine constrain targeting ppc64le?
Clang forwards inline assembly to LLVM, so the supported constraints are documented there in https://llvm.org/docs/LangRef.html#supported-constraint-code-list:
es, o, Q, Z, Zy: A memory address operand, currently treated the same as m.
And no YZ. It should be mentioned that this is the documentation for the current development branch. Releases are under e.g. https://releases.llvm.org/19.1.0/docs/LangRef.html#supported-constraint-code... for the latest major version. (In reply to Jiri Slaby from comment #7)
WIW it doesn't make sense (read as: is invalid/undefined) to build modules with a different compiler.
From my understanding bcc doesn't build native kernel modules but just BPF code. Headers are to my understanding only used for data layout, because functions could contain inline assembly, which doesn't work in BPF. Though it's an interesting question: what if a header file uses inline assembly in inline functions? BPF doesn't have (?) inline assembly, or at least different constraints than the bare metal target. Since invalid constraints are being diagnosed in the frontend, it would complain about them even if the function isn't being used and thus emitted. (In reply to Jiri Slaby from comment #8)
The header is not uapi, hence not exported.
Internal headers are probably used to get the layout of certain data structures. After all the idea of these scripts is to be able to look inside the kernel. As such, I guess they're inherently a bit fragile and whether they work or not can depend on the kernel version. (In reply to Michal Suchanek from comment #9)
Indeed, then it should use the system compiler for that.
My understanding is that bcc doesn't use any compiler directly, but is instead based on the Clang libraries. So it cannot use GCC, at least not without a substantial rewrite. I think it predates the BPF backend in GCC. -- You are receiving this mail because: You are the assignee for the bug.