(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/src/cc/frontends/clang/loader.cc#L416, and adds a flag "-D__TARGET_ARCH_" + arch here: https://github.com/iovisor/bcc/blob/cb1ba20f4800f556dc940682ba7016c50bd0a3ac/src/cc/frontends/clang/kbuild_helper.cc#L134. 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.