When compiling the kernel there's no type definition for u32 within the
translation unit causing compilation errors of the following format:
btf_ids.h:7:2: error: unknown type name ‘u32’
To avoid such errors it's possible to include the common header file
linux/types.h containing the required definition.
Signed-off-by: Dmitrii Bundin <[email protected]>
---
tools/include/linux/btf_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/linux/btf_ids.h b/tools/include/linux/btf_ids.h
index 72535f00572f..7969607efe0d 100644
--- a/tools/include/linux/btf_ids.h
+++ b/tools/include/linux/btf_ids.h
@@ -3,6 +3,8 @@
#ifndef _LINUX_BTF_IDS_H
#define _LINUX_BTF_IDS_H
+#include <linux/types.h>
+
struct btf_id_set {
u32 cnt;
u32 ids[];
--
2.17.1
On Fri, Mar 15, 2024 at 2:15 AM Dmitrii Bundin
<[email protected]> wrote:
>
> When compiling the kernel there's no type definition for u32 within the
> translation unit causing compilation errors of the following format:
>
> btf_ids.h:7:2: error: unknown type name ‘u32’
What compiler? What setup?
Steps to repro?
No one reported this, though lots of people
are building resolve_btfids that uses this header
as part of the kernel build.
pw-bot: cr
On Fri, Mar 15, 2024 at 6:41 PM Alexei Starovoitov
<[email protected]> wrote:
> No one reported this, though lots of people
> are building resolve_btfids that uses this header
> as part of the kernel build.
GCC version 7.5.0, GNU Make 4.1
Steps to reproduce:
1. Check out the commit e5eb28f6d1afebed4bb7d740a797d0390bd3a357
2. cd tools/bpf/resolve_btfids/
3. make
The steps above produces the following error messages (similar error
output truncated for clarity):
In file included from main.c:73:0:
/linux/tools/include/linux/btf_ids.h:7:2: error: unknown type name ‘u32’
u32 cnt;
^~~
The other sources including <linux/btf_ids.h> usually includes
(directly or indirectly) <linux/types.h> before which is not the case
for tools/bpf/resolve_btfids/main.c. So that looks reasonable to me to
bring all the required type definitions into scope explicitly in
linux/btf_ids.h. Any thoughts on this?
On Fri, Mar 15, 2024 at 10:09 AM Dmitrii Bundin
<[email protected]> wrote:
>
> On Fri, Mar 15, 2024 at 6:41 PM Alexei Starovoitov
> <[email protected]> wrote:
> > No one reported this, though lots of people
I'm also seeing this, on clang.
> > are building resolve_btfids that uses this header
> > as part of the kernel build.
>
> GCC version 7.5.0, GNU Make 4.1
> Steps to reproduce:
> 1. Check out the commit e5eb28f6d1afebed4bb7d740a797d0390bd3a357
> 2. cd tools/bpf/resolve_btfids/
> 3. make
>
> The steps above produces the following error messages (similar error
> output truncated for clarity):
>
> In file included from main.c:73:0:
> /linux/tools/include/linux/btf_ids.h:7:2: error: unknown type name ‘u32’
> u32 cnt;
yup, that's the error I'm seeing.
> ^~~
>
> The other sources including <linux/btf_ids.h> usually includes
> (directly or indirectly) <linux/types.h> before which is not the case
> for tools/bpf/resolve_btfids/main.c. So that looks reasonable to me to
> bring all the required type definitions into scope explicitly in
> linux/btf_ids.h. Any thoughts on this?
>
On Mon, Mar 18, 2024 at 7:56 PM Khazhy Kumykov <[email protected]> wrote:
> I'm also seeing this, on clang.
I think the error is more related to the libc version. I updated the
libc6 to 2.35 and noticed that the <linux/types.h> header is included
indirectly through <sys/stat.h>. The relevant sample of the include
hierarchy for <sys/stat.h> with libc6 v2.35 looks as follows:
/usr/include/x86_64-linux-gnu/sys/stat.h
. /usr/include/x86_64-linux-gnu/bits/stat.h
.. /usr/include/x86_64-linux-gnu/bits/struct_stat.h
. /usr/include/x86_64-linux-gnu/bits/statx.h
.. /linux/tools/include/uapi/linux/stat.h
... /linux/tools/include/linux/types.h
The <linux/types.h> is included on the latest line of the sample.
Starting the version 2.28 there's an inclusion of <bits/statx.h> which
was not presented in 2.27.
When building the resolve_btfids with the libc6 version 2.27
<linux/types.h> is not included through <sys/stat.h>. The include
hierarchy for <sys/stat.h> with libc6 v2.27 looks as follows:
/usr/include/x86_64-linux-gnu/sys/stat.h
. /usr/include/x86_64-linux-gnu/bits/stat.h
/usr/include/fcntl.h
To avoid being dependent on the inclusion of <linux/types.h> at some
other place it looks reasonable to include it explicitly to bring all
the necessary declarations before their usage.
What do you think?
On Thu, Mar 21, 2024 at 12:51 PM Dmitrii Bundin
<[email protected]> wrote:
>
> On Mon, Mar 18, 2024 at 7:56 PM Khazhy Kumykov <[email protected]> wrote:
> > I'm also seeing this, on clang.
>
> I think the error is more related to the libc version. I updated the
> libc6 to 2.35 and noticed that the <linux/types.h> header is included
> indirectly through <sys/stat.h>. The relevant sample of the include
> hierarchy for <sys/stat.h> with libc6 v2.35 looks as follows:
>
> . /usr/include/x86_64-linux-gnu/sys/stat.h
> .. /usr/include/x86_64-linux-gnu/bits/stat.h
> ... /usr/include/x86_64-linux-gnu/bits/struct_stat.h
> .. /usr/include/x86_64-linux-gnu/bits/statx.h
> ... /linux/tools/include/uapi/linux/stat.h
> .... /linux/tools/include/linux/types.h
>
> The <linux/types.h> is included on the latest line of the sample.
> Starting the version 2.28 there's an inclusion of <bits/statx.h> which
> was not presented in 2.27.
>
> When building the resolve_btfids with the libc6 version 2.27
> <linux/types.h> is not included through <sys/stat.h>. The include
> hierarchy for <sys/stat.h> with libc6 v2.27 looks as follows:
>
> . /usr/include/x86_64-linux-gnu/sys/stat.h
> .. /usr/include/x86_64-linux-gnu/bits/stat.h
> . /usr/include/fcntl.h
>
> To avoid being dependent on the inclusion of <linux/types.h> at some
> other place it looks reasonable to include it explicitly to bring all
> the necessary declarations before their usage.
I would agree - include what you use. The u32 type is defined in
linux/types.h, relying on indirect includes seems fragile (and in this
case, does seem to break folks).
>
> What do you think?