mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 15:40:56 +07:00
1d1a3bcffe
It's been a recurring issue with types like u32 slipping into libbpf source
code accidentally. This is not detected during builds inside kernel source
tree, but becomes a compilation error in libbpf's Github repo. Libbpf is
supposed to use only __{s,u}{8,16,32,64} typedefs, so poison {s,u}{8,16,32,64}
explicitly in every .c file. Doing that in a bit more centralized way, e.g.,
inside libbpf_internal.h breaks selftests, which are both using kernel u32 and
libbpf_internal.h.
This patch also fixes a new u32 occurence in libbpf.c, added recently.
Fixes: 590a008882 ("bpf: libbpf: Add STRUCT_OPS support")
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20200110181916.271446-1-andriin@fb.com
22 lines
636 B
C
22 lines
636 B
C
// SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
|
|
#undef _GNU_SOURCE
|
|
#include <string.h>
|
|
#include <stdio.h>
|
|
#include "str_error.h"
|
|
|
|
/* make sure libbpf doesn't use kernel-only integer typedefs */
|
|
#pragma GCC poison u8 u16 u32 u64 s8 s16 s32 s64
|
|
|
|
/*
|
|
* Wrapper to allow for building in non-GNU systems such as Alpine Linux's musl
|
|
* libc, while checking strerror_r() return to avoid having to check this in
|
|
* all places calling it.
|
|
*/
|
|
char *libbpf_strerror_r(int err, char *dst, int len)
|
|
{
|
|
int ret = strerror_r(err < 0 ? -err : err, dst, len);
|
|
if (ret)
|
|
snprintf(dst, len, "ERROR: strerror_r(%d)=%d", err, ret);
|
|
return dst;
|
|
}
|