New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clang macro-redefined warnings in newer kernel versions #3366
Comments
This can be easily fixed by not warning about macro redefinitions. I've tried it here and it works fine. |
Do you plan to propose this in a PR? It certainly improve the situation. |
Can do later today, sure. |
Looks like this may be the kernel change causing the warning. In bcc these cflags were first added in e3b3b4c, then moved to their current location in b83ccf3 . I've been trying to figure out a way to fix this that's more precise than #3385 but as @hhoffstaette mentioned it's not looking straightforward. I think moving the |
As reported in iovisor#3366, on newer kernels bcc complains about macro redefinition when compiling bpf programs: ``` include/linux/compiler-clang.h:46:9: warning: '__HAVE_BUILTIN_BSWAP64__' macro redefined [-Wmacro-redefined] \#define __HAVE_BUILTIN_BSWAP64__ ^ <command line>:5:9: note: previous definition is here \#define __HAVE_BUILTIN_BSWAP64__ 1 ``` Since these macros are passed in as `-D` cflags, they appear first before any \#define statements in code. Since an [upstream kernel patch](https://lore.kernel.org/linux-csky/20210226161151.2629097-1-arnd@kernel.org/) added these defines in a kernel header, we see the warning. This patch moves these definitions to a separate 'virtual' header that's included after virtual_bpf.h and adds an ifndef guard. As a result, newer kernels with the patch will not trigger the warning, while older kernels will not lose the definition. This should be safe based on my digging - some existing bcc programs use `__builtin_bswap` methods, but without checking HAVE_BUILTIN_BSWAP. Macros that may be conditionally defined based on HAVE_BUILTIN_BSWAP, like those in `bpf_endian.h`, aren't. If a similar macro or struct def in virtual_bpf.h - or any header it pulls in - changes depending on HAVE_BUILTIN_BSWAP this could cause problems on older kernels, but I don't believe that this is the case, or will be based on how infrequently the defines are checked.
As reported in iovisor#3366, on newer kernels bcc complains about macro redefinition when compiling bpf programs: ``` include/linux/compiler-clang.h:46:9: warning: '__HAVE_BUILTIN_BSWAP64__' macro redefined [-Wmacro-redefined] \#define __HAVE_BUILTIN_BSWAP64__ ^ <command line>:5:9: note: previous definition is here \#define __HAVE_BUILTIN_BSWAP64__ 1 ``` Since these macros are passed in as `-D` cflags, they appear first before any \#define statements in code. Since an [upstream kernel patch](https://lore.kernel.org/linux-csky/20210226161151.2629097-1-arnd@kernel.org/) added these defines in a kernel header, we see the warning. This patch moves these definitions to a separate 'virtual' header that's included after virtual_bpf.h and adds an ifndef guard. As a result, newer kernels with the patch will not trigger the warning, while older kernels will not lose the definition. This should be safe based on my digging - some existing bcc programs use `__builtin_bswap` methods, but without checking HAVE_BUILTIN_BSWAP. Macros that may be conditionally defined based on HAVE_BUILTIN_BSWAP, like those in `bpf_endian.h`, aren't. If a similar macro or struct def in virtual_bpf.h - or any header it pulls in - changes depending on HAVE_BUILTIN_BSWAP this could cause problems on older kernels, but I don't believe that this is the case, or will be based on how infrequently the defines are checked.
As reported in iovisor#3366, on newer kernels bcc complains about macro redefinition when compiling bpf programs: ``` include/linux/compiler-clang.h:46:9: warning: '__HAVE_BUILTIN_BSWAP64__' macro redefined [-Wmacro-redefined] \#define __HAVE_BUILTIN_BSWAP64__ ^ <command line>:5:9: note: previous definition is here \#define __HAVE_BUILTIN_BSWAP64__ 1 ``` Since these macros are passed in as `-D` cflags, they appear first before any \#define statements in code. Since an [upstream kernel patch](https://lore.kernel.org/linux-csky/20210226161151.2629097-1-arnd@kernel.org/) added these defines in a kernel header, we see the warning. This patch moves these definitions to a separate 'virtual' header that's included after virtual_bpf.h and adds an ifndef guard. As a result, newer kernels with the patch will not trigger the warning, while older kernels will not lose the definition. This should be safe based on my digging - some existing bcc programs use `__builtin_bswap` methods, but without checking HAVE_BUILTIN_BSWAP. Macros that may be conditionally defined based on HAVE_BUILTIN_BSWAP, like those in `bpf_endian.h`, aren't. If a similar macro or struct def in virtual_bpf.h - or any header it pulls in - changes depending on HAVE_BUILTIN_BSWAP this could cause problems on older kernels, but I don't believe that this is the case, or will be based on how infrequently the defines are checked.
As reported in #3366, on newer kernels bcc complains about macro redefinition when compiling bpf programs: ``` include/linux/compiler-clang.h:46:9: warning: '__HAVE_BUILTIN_BSWAP64__' macro redefined [-Wmacro-redefined] \#define __HAVE_BUILTIN_BSWAP64__ ^ <command line>:5:9: note: previous definition is here \#define __HAVE_BUILTIN_BSWAP64__ 1 ``` Since these macros are passed in as `-D` cflags, they appear first before any \#define statements in code. Since an [upstream kernel patch](https://lore.kernel.org/linux-csky/20210226161151.2629097-1-arnd@kernel.org/) added these defines in a kernel header, we see the warning. This patch moves these definitions to a separate 'virtual' header that's included after virtual_bpf.h and adds an ifndef guard. As a result, newer kernels with the patch will not trigger the warning, while older kernels will not lose the definition. This should be safe based on my digging - some existing bcc programs use `__builtin_bswap` methods, but without checking HAVE_BUILTIN_BSWAP. Macros that may be conditionally defined based on HAVE_BUILTIN_BSWAP, like those in `bpf_endian.h`, aren't. If a similar macro or struct def in virtual_bpf.h - or any header it pulls in - changes depending on HAVE_BUILTIN_BSWAP this could cause problems on older kernels, but I don't believe that this is the case, or will be based on how infrequently the defines are checked.
Is this the same thing?
|
@l1x yeah, looks like the issue is back, or perhaps my earlier fix didn't work, will investigate |
Let me know how can I help. |
Still getting a warning on it
|
When running
|
on ubuntu:22.04, and docker/for-desktop-kernel:5.10.76-505289bcc85427a04d8d797e06cbca92eee291f4, still got this warning:
|
@zhangxiang958 Please build BCC from source. |
This might help someone somewhere, so here is how I solved it after a long struggle : bpf = BPF(text=program, usdt_contexts=[usdt] if usdt else [], cflags=["-Wno-macro-redefined"]) |
@ayoubeddafali NameError: name 'usdt' is not defined |
build BCC from source is ok |
kernel version : 5.10.134-12.2 In file included from :2: |
In order to help others to find the repository, I suggest to include the github repository. I faced an issue with warnings when I tried to install the BCC and I could find the solution by installing the BCC through the source code(iovisor/bcc#3366) . I don't know if it could be useful to include this information here somewhere. Signed-off-by: edualb <39157101+edualb@users.noreply.github.com>
Brings in a newer version of bcc to help with iovisor/bcc#3366. Compiling from source isn't work I wanna do.
When running on 5.10.29, I get the following warning:
This happens for all bcc related tools (we use bcc v0.19.0)
The text was updated successfully, but these errors were encountered: