On 6/7/21 9:08 PM, Andrii Nakryiko wrote:
On Mon, Jun 7, 2021 at 7:41 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote:
On 6/7/21 5:25 PM, Andrii Nakryiko wrote:
On Mon, Jun 7, 2021 at 4:12 PM Tom Stellard <tstellar@xxxxxxxxxx> wrote:
Hi,
+ } else {
+ pr_warn("relocation against STT_SECTION in non-exec section is not supported!\n");
+ return -EINVAL;
+ }
Kernel build of commit 324c92e5e0ee are failing for me with this error
message:
/builddir/build/BUILD/kernel-5.13-rc4-61-g324c92e5e0ee/linux-5.13.0-0.rc4.20210603git324c92e5e0ee.35.fc35.x86_64/tools/bpf/bpftool/bpftool gen object /builddir/build/BUILD/kernel-5.13-rc4-61-g324c92e5e0ee/linux-5.13.0-0.rc4.20210603git324c92e5e0ee.35.fc35.x86_64/tools/testing/selftests/bpf/bind_perm.linked1.o /builddir/build/BUILD/kernel-5.13-rc4-61-g324c92e5e0ee/linux-5.13.0-0.rc4.20210603git324c92e5e0ee.35.fc35.x86_64/tools/testing/selftests/bpf/bind_perm.o
libbpf: relocation against STT_SECTION in non-exec section is not supported!
What information can I provide to help debug this failure?
Can you please send that bind_perm.o file? Also what's your `clang
--version` output?
clang version 12.0.0 (Fedora 12.0.0-2.fc35)
I suspect this might be due to Clang commit 6a2ea84600ba ("BPF: Add
more relocation kinds"), but I get a different error on 324c92e5e0ee.
So meanwhile you might try applying 9f0c317f6aa1 ("libbpf: Add support
for new llvm bpf relocations") from bpf-next/master and check if that
helps. But please do share bind_perm.o, just to double-check what's
going on.
Here is bind_perm.o: https://fedorapeople.org/~tstellar/bind_perm.o
So somehow you end up with .eh_frame section in BPF object file, which
shouldn't ever happen. So there must be something that you are doing
differently (compiler flags or something else) that makes Clang
produce .eh_frame. So we need to figure out why .eh_frame gets
generated. Not sure how, but maybe you have some ideas of what might
be different about your build.
Tom,
I tried with latest release/12.x branch with top commit
0826268d59c6 [PowerPC] Fix x86 vector intrinsics wrapper
compilation under C++
and I cannot reproduce the issue.
$ clang --version
clang version 12.0.1 (https://github.com/llvm/llvm-project.git
0826268d59c6e1bb3530dffd9dc5f6038774486d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
The following is my compilation flag, captured with
make -C tools/testing/selftests/bpf -j60 V=1
$ cat log.sh
clang -g -D__TARGET_ARCH_x86 -mlittle-endian
-I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include
-I/home/yhs/work/bpf-next/tools/testing/selftests/bpf
-I/home/yhs/work/bpf-next/tools/include/uapi
-I/home/yhs/work/bpf-next/tools/testing/selftests/usr/include -idirafter
/home/yhs/work/llvm-project/llvm/build.cur/install/lib/clang/13.0.0/include
-idirafter /usr/local/include -idirafter /usr/include
-Wno-compare-distinct-pointer-types -DENABLE_ATOMICS_TESTS -O2 -target
bpf -c progs/bind_perm.c -o
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/bind_perm.o -mcpu=v3
Looking at progs/bind_perm.c, I can see
#include <linux/stddef.h>
#include <linux/bpf.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>
So it included some system header files. Maybe some of these
header files changed some function attributes which triggered
.cfi_startproc/.cfi_endproc generation which enabled .eh_frame section
generation.
Maybe you can produce an .i file in your environment
so we can do some further analysis.
Thanks,
Tom
Thanks,
Tom
