From: Jakub Sitnicki <jakub@cloudflare.com>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
kernel-team@fb.com, kernel-team@cloudflare.com
Subject: Re: [PATCH bpf-next] libbpf: fix internal USDT address translation logic for shared libraries
Date: Wed, 20 Jul 2022 20:32:09 +0200 [thread overview]
Message-ID: <87czdzy6k2.fsf@cloudflare.com> (raw)
In-Reply-To: <87lesnyeph.fsf@cloudflare.com>
On Wed, Jul 20, 2022 at 05:32 PM +02, Jakub Sitnicki wrote:
[...]
>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
>> index 8ad7a733a505..e08e8e34e793 100644
>> --- a/tools/testing/selftests/bpf/Makefile
>> +++ b/tools/testing/selftests/bpf/Makefile
>> @@ -172,13 +172,15 @@ $(OUTPUT)/%:%.c
>> # do not fail. Static builds leave urandom_read relying on system-wide shared libraries.
>> $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c
>> $(call msg,LIB,,$@)
>> - $(Q)$(CC) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $^ $(LDLIBS) -fPIC -shared -o $@
>> + $(Q)$(CLANG) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $^ $(LDLIBS) \
>> + -fuse-ld=lld -Wl,-znoseparate-code -fPIC -shared -o $@
>>
>> $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
>> $(call msg,BINARY,,$@)
>> - $(Q)$(CC) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
>> - liburandom_read.so $(LDLIBS) \
>> - -Wl,-rpath=. -Wl,--build-id=sha1 -o $@
>> + $(Q)$(CLANG) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
>> + liburandom_read.so $(LDLIBS) \
>> + -fuse-ld=lld -Wl,-znoseparate-code \
>> + -Wl,-rpath=. -Wl,--build-id=sha1 -o $@
>
> [...]
>
> Not sure if this was considered - adding a dependency on Clang for the
> target platform makes cross-compiling bpf selftests much harder than it
> was.
>
> Maybe we could use $(CLANG) only when not cross-compiling, and execute
> $(CC) like before otherwise?
OTOH, there seems to be nothing Clang specific about the build
recipe. We just want t use LLVM lld. GCC accepts -fuse-ld as well (bfd
vs lld).
Perhaps we could partially revert to something as below? It "fixes" the
cross-compilation build of bpf selftests for arm64 for me.
WDYT?
--8<--
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 8d59ec7f4c2d..541e2b0de27a 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -170,24 +170,24 @@ $(OUTPUT)/%:%.c
# LLVM's ld.lld doesn't support all the architectures, so use it only on x86
ifeq ($(SRCARCH),x86)
-LLD := lld
+ALT_LD := lld
else
-LLD := ld
+ALT_LD := bfd
endif
# Filter out -static for liburandom_read.so and its dependent targets so that static builds
# do not fail. Static builds leave urandom_read relying on system-wide shared libraries.
$(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c
$(call msg,LIB,,$@)
- $(Q)$(CLANG) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $^ $(LDLIBS) \
- -fuse-ld=$(LLD) -Wl,-znoseparate-code -fPIC -shared -o $@
+ $(Q)$(CC) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $^ $(LDLIBS) \
+ -fuse-ld=$(ALT_LD) -Wl,-znoseparate-code -fPIC -shared -o $@
$(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
$(call msg,BINARY,,$@)
- $(Q)$(CLANG) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
- liburandom_read.so $(LDLIBS) \
- -fuse-ld=$(LLD) -Wl,-znoseparate-code \
- -Wl,-rpath=. -Wl,--build-id=sha1 -o $@
+ $(Q)$(CC) $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
+ liburandom_read.so $(LDLIBS) \
+ -fuse-ld=$(ALT_LD) -Wl,-znoseparate-code \
+ -Wl,-rpath=. -Wl,--build-id=sha1 -o $@
$(OUTPUT)/bpf_testmod.ko: $(VMLINUX_BTF) $(wildcard bpf_testmod/Makefile bpf_testmod/*.[ch])
$(call msg,MOD,,$@)
next prev parent reply other threads:[~2022-07-20 18:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 5:55 [PATCH bpf-next] libbpf: fix internal USDT address translation logic for shared libraries Andrii Nakryiko
2022-06-16 19:59 ` Alexei Starovoitov
2022-06-16 20:38 ` Andrii Nakryiko
2022-06-16 23:30 ` patchwork-bot+netdevbpf
2022-07-20 15:32 ` Jakub Sitnicki
2022-07-20 18:32 ` Jakub Sitnicki [this message]
2022-07-28 22:04 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czdzy6k2.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@cloudflare.com \
--cc=kernel-team@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.