All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Jihong <yangjihong1@huawei.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: <peterz@infradead.org>, <mingo@redhat.com>, <acme@kernel.org>,
	<mark.rutland@arm.com>, <alexander.shishkin@linux.intel.com>,
	<jolsa@kernel.org>, <namhyung@kernel.org>, <ast@kernel.org>,
	<daniel@iogearbox.net>, <andrii@kernel.org>, <kafai@fb.com>,
	<songliubraving@fb.com>, <yhs@fb.com>, <john.fastabend@gmail.com>,
	<kpsingh@kernel.org>, <nathan@kernel.org>, <trix@redhat.com>,
	<ak@linux.intel.com>, <adrian.hunter@intel.com>,
	<james.clark@arm.com>, <linux-perf-users@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<bpf@vger.kernel.org>, <llvm@lists.linux.dev>
Subject: Re: [PATCH] perf llvm: Fix compile bpf failed to cope with latest llvm
Date: Fri, 15 Apr 2022 11:53:46 +0800	[thread overview]
Message-ID: <6d7635be-e694-0132-e2b2-e6816c34aa72@huawei.com> (raw)
In-Reply-To: <CAKwvOdmZCS784R5myuA=MgSnxQfS6sPUsBKbbax_QN1fSMNzbQ@mail.gmail.com>

On 2022/4/14 23:57, Nick Desaulniers wrote:
> On Thu, Apr 14, 2022 at 6:42 AM Yang Jihong <yangjihong1@huawei.com> wrote:
>>
>> Inline assembly used by asm/sysreg.h is incompatible with latest llvm,
> 
> With "latest" llvm makes it sound like LLVM has regressed. Has it? Or
> have the headers changed in a way where now inline asm from a
> different target (x86) than what's being targeted (BPF)? Perhaps
> fixing that is simpler?
> 
> Clang will validate inline asm before LLVM drops unreferenced static
> inline functions; this was a headache getting i386 building with
> clang, but not insurmountable.
> 
According to the notes of samples/bpf/Makefile:
"The reason is due to llvm change https://reviews.llvm.org/D87153
where the CORE relocation global generation is moved from the beginning
of target dependent optimization (llc) to the beginning
of target independent optimization (opt).

Since samples/bpf programs did not use vmlinux.h and its clang compilation
uses native architecture, we need to adjust arch triple at opt level
to do CORE relocation global generation properly. Otherwise, the above
error will appear."
I think opt and llvm-dis are introduced to solve another problem, that 
is, the incompatibility of native architecture.

>> If bpf C program include "linux/ptrace.h" (which is common), compile will fail:
>>
>>   # perf --debug verbose record -e bpf-output/no-inherit,name=evt/ \
>>                                -e ./perf_bpf_test.c/map:channel.event=evt/ ls
>>   [SNIP]
>>   /lib/modules/5.17/build/./arch/x86/include/asm/arch_hweight.h:20:7: error: invalid output constraint '=a' in asm
>>                            : "="REG_OUT (res)
>>                             ^
>>   /lib/modules/5.17/build/./arch/x86/include/asm/arch_hweight.h:48:7: error: invalid output constraint '=a' in asm
>>                            : "="REG_OUT (res)
>>                             ^
>>   In file included from /root/projects/perf-bpf/perf_bpf_test.c:2:
>>   In file included from /lib/modules/5.17/build/./include/linux/ptrace.h:6:
>>   In file included from /lib/modules/5.17/build/./include/linux/sched.h:12:
>>   In file included from /lib/modules/5.17/build/./arch/x86/include/asm/current.h:6:
>>   In file included from /lib/modules/5.17/build/./arch/x86/include/asm/percpu.h:27:
>>   In file included from /lib/modules/5.17/build/./include/linux/kernel.h:25:
>>   In file included from /lib/modules/5.17/build/./include/linux/math.h:6:
>>   /lib/modules/5.17.0/build/./arch/x86/include/asm/div64.h:85:28: error: invalid output constraint '=a' in asm
>>           asm ("mulq %2; divq %3" : "=a" (q)
>>   [SNIP]
>>   # cat /root/projects/perf-bpf/perf_bpf_test.c
>>   /************************ BEGIN **************************/
>>   #include <uapi/linux/bpf.h>
>>   #include <linux/ptrace.h>
>>   #include <linux/types.h>
>>   #define SEC(NAME) __attribute__((section(NAME), used))
>>
>>   struct bpf_map_def {
>>           unsigned int type;
>>           unsigned int key_size;
>>           unsigned int value_size;
>>           unsigned int max_entries;
>>   };
>>
>>   static int (*perf_event_output)(void *, struct bpf_map_def *, int, void *,
>>       unsigned long) = (void *)BPF_FUNC_perf_event_output;
>>
>>   struct bpf_map_def SEC("maps") channel = {
>>           .type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
>>           .key_size = sizeof(int),
>>           .value_size = sizeof(__u32),
>>           .max_entries = __NR_CPUS__,
>>   };
>>
>>   #define MIN_BYTES 1024
>>
>>   SEC("func=vfs_read")
>>   int bpf_myprog(struct pt_regs *ctx)
>>   {
>>           long bytes = ctx->dx;
>>           if (bytes >= MIN_BYTES) {
>>                   perf_event_output(ctx, &channel, BPF_F_CURRENT_CPU,
>>                                     &bytes, sizeof(bytes));
>>           }
>>
>>           return 0;
>>   }
>>
>> char _license[] SEC("license") = "GPL";
>> int _version SEC("version") = LINUX_VERSION_CODE;
>> /************************* END ***************************/
>>
>> Compilation command is modified to be the same as that in samples/bpf/Makefile,
>> use clang | opt | llvm-dis | llc chain of commands to solve the problem.
>> see the comment in samples/bpf/Makefile.
>>
>> Modifications:
>> 1. Change "clang --target bpf" to chain of commands "clang | opt | llvm-dis | llc"
> 
> This will drop the --target flag. That will mess up the default target
> triple, and can affect command line option feature detection.
> 
opt add -mtriple=bpf-pc-linux flag,
The complete command is as follows:
clang -O2 -emit-llvm -Xclang -disable-llvm-passes -c $< -o - |
opt -O2 -mtriple=bpf-pc-linux | $(LLVM_DIS) | \
llc -march=bpf $(LLC_FLAGS) -filetype=obj -o $@

This may be a problem. Currently, no simple method is found. Therefore, 
refer to the processing method of samles/bpf/Makefile.

-- 
Thanks,
Jihong


      reply	other threads:[~2022-04-15  3:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 13:41 [PATCH] perf llvm: Fix compile bpf failed to cope with latest llvm Yang Jihong
2022-04-14 15:57 ` Nick Desaulniers
2022-04-15  3:53   ` Yang Jihong [this message]

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=6d7635be-e694-0132-e2b2-e6816c34aa72@huawei.com \
    --to=yangjihong1@huawei.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=james.clark@arm.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    --cc=trix@redhat.com \
    --cc=yhs@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.