https://bugzilla.suse.com/show_bug.cgi?id=1231247 https://bugzilla.suse.com/show_bug.cgi?id=1231247#c1 --- Comment #1 from Avinesh Kumar <avinesh.kumar@suse.com> --- $ /usr/share/bcc/tools/btrfsdist 5 2 .. .. In file included from /virtual/main.c:3: include/linux/fs.h:3661:15: error: invalid input constraint 'YZ<>' in asm 3661 | if (unlikely(get_user(c, path))) | ^ arch/powerpc/include/asm/uaccess.h:322:5: note: expanded from macro 'get_user' 322 | __get_user(x, _gu_addr) : \ | ^ arch/powerpc/include/asm/uaccess.h:310:2: note: expanded from macro '__get_user' 310 | __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \ | ^ arch/powerpc/include/asm/uaccess.h:226:3: note: expanded from macro '__get_user_size_allowed' 226 | __get_user_size_goto(x, ptr, size, __gus_failed); \ | ^ arch/powerpc/include/asm/uaccess.h:217:10: note: expanded from macro '__get_user_size_goto' 217 | case 8: __get_user_asm2_goto(x, (u64 __user *)ptr, label); break; \ | ^ arch/powerpc/include/asm/uaccess.h:193:5: note: expanded from macro '__get_user_asm2_goto' 193 | : DS_FORM_CONSTRAINT (*addr) \ | ^ arch/powerpc/include/asm/uaccess.h:98:28: note: expanded from macro 'DS_FORM_CONSTRAINT' 98 | #define DS_FORM_CONSTRAINT "YZ<>" | ^ 1 error generated. Traceback (most recent call last): File "/usr/share/bcc/tools/btrfsdist", line 204, in <module> b = BPF(text=bpf_text) ^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/bcc/__init__.py", line 479, in __init__ raise Exception("Failed to compile BPF module %s" % (src_file or "<text>")) Exception: Failed to compile BPF module <text> -- You are receiving this mail because: You are the assignee for the bug.

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.

https://bugzilla.suse.com/show_bug.cgi?id=1231247 https://bugzilla.suse.com/show_bug.cgi?id=1231247#c12 --- Comment #12 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Aaron Puchert from comment #10)

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.

Hmm, it could also be that kernel headers are being parsed under the native target, since the data layout depends on that to some extent. Then maybe this concern is void and we're only running into this because Clang/LLVM doesn't support this particular constraint on ppc64le. (In reply to Michal Suchanek from comment #6)

Instead of checking CC_IS_CLANG which is kernel-specific and not defined when the header is used by userspace it should check some define that is provided by clang compiler itself.

It could use __clang__. Or bcc could (as a dirty hack) define CC_IS_CLANG. -- You are receiving this mail because: You are the assignee for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1231247 https://bugzilla.suse.com/show_bug.cgi?id=1231247#c15 --- Comment #15 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- (In reply to Jiri Slaby from comment #14)

and then somehow processes it there: https://github.com/iovisor/bcc/blob/cb1ba20f4800f556dc940682ba7016c50bd0a3ac... src/cc/bpf_module.cc#L550

That answers my question about target vs data layout. This is in the backend, where we emit code for the BPF target (of course): mod->setTargetTriple("bpf-pc-linux"); #if LLVM_VERSION_MAJOR >= 11 #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ mod->setDataLayout("e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"); #else mod->setDataLayout("E-m:e-p:64:64-i64:64-i128:128-n32:64-S128"); #endif #else // ... #endif It sets the data layout manually based on the native architecture. The Clang frontend however uses the native target: https://github.com/iovisor/bcc/blob/cb1ba20f4800f556dc940682ba7016c50bd0a3ac..., and adds a flag "-D__TARGET_ARCH_" + arch here: https://github.com/iovisor/bcc/blob/cb1ba20f4800f556dc940682ba7016c50bd0a3ac.... So we tell the frontend that we want to compile for the native target (so we get the right defines and data layout), but then switch the target to BPF before we hand the IR to the backend. To make sure both agree on the data layout, we set it manually for the BPF backend to match the native target. What does this mean for inline assembly? The frontend won't complain about it, because it thinks we're compiling for the native target (unless Clang/LLVM don't know this particular constraint). The inline assembly itself is never emitted, because we don't use any functions from the included headers. So the (BPF) backend doesn't complain. At least that's my current theory. -- You are receiving this mail because: You are the assignee for the bug.