From: "Wangnan (F)" <wangnan0@huawei.com>
To: Alexei Starovoitov <ast@plumgrid.com>,
He Kuang <hekuang@huawei.com>, pi3orama <pi3orama@163.com>
Cc: <llvm-dev@lists.llvm.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Date: Wed, 5 Aug 2015 14:51:00 +0800 [thread overview]
Message-ID: <55C1B254.5030801@huawei.com> (raw)
In-Reply-To: <55C16F53.3070604@huawei.com>
On 2015/8/5 10:05, Wangnan (F) wrote:
> Send again since llvmdev is moved to llvm-dev@lists.llvm.org
>
> On 2015/8/5 9:58, Wangnan (F) wrote:
>>
>>>
>>> On 2015/8/4 3:44, Alexei Starovoitov wrote:
>>>> On 7/31/15 3:18 AM, Wangnan (F) wrote:
>>>>
>>>
>>> [SNIP]
>>>
>>>> didn't have time to look at it.
>>>> from your llvm patches looks like you've got quite experienced
>>>> with it already :)
>>>>
>>>>> I'll post 2 LLVM patches by replying this mail. Please have a look
>>>>> and
>>>>> help me
>>>>> send them to LLVM if you think my code is correct.
>>>>
>>>> patch 1:
>>>> I don't quite understand the purpose of builtin_dwarf_cfa
>>>> returning R11. It's a special register seen inside llvm codegen
>>>> only. It doesn't have kernel meaning.
>>>>
>>>
>>> Kernel side verifier allows us to do arithmetic computation using
>>> two local variable
>>> address or local variable address and R11. Therefore, we can compute
>>> the location
>>> of a local variable using:
>>>
>>> mark = &my_var_a - __builtin_frame_address(0);
>>>
>>> If the stack allocation is fixed (if the location is never reused),
>>> the above 'mark'
>>> can be uniquely identify a local variable. That's why I'm
>>> interesting in it. However
>>> I'm not sure whether the prerequestion is hold.
>>>
>>>> patch 2:
>>>> do we really need to hack clang?
>>>> Can you just define a function that aliases to intrinsic,
>>>> like we do for ld_abs/ld_ind ?
>>>> void bpf_store_half(void *skb, u64 off, u64 val)
>>>> asm("llvm.bpf.store.half");
>>>> then no extra patches necessary.
>>>>
And for this:
I tried this test function:
void bpf_store_half(void *skb, int off, int val) asm("llvm.bpf.store.half");
int func()
{
bpf_store_half(0, 0, 0);
return 0;
}
Compiled with:
$ clang -g -target bpf -O2 -S -c test.c
And get this:
.text
.globl func
.align 8
func: # @func
# BB#0: # %entry
mov r1, 0
mov r2, 0
mov r3, 0
call llvm.bpf.store.half
mov r0, 0
ret
Without -S, it generate a function relocation:
$ objdump -r ./test.o
./test.o: file format elf64-little
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000018 UNKNOWN llvm.bpf.store.half
It doesn't work as you suggestion. I think we still need to do something
in clang frontend, or it can only be used in '.ll'.
Thank you.
next prev parent reply other threads:[~2015-08-05 6:51 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 10:03 [RFC PATCH v4 0/3] Make eBPF programs output data to perf event He Kuang
2015-07-10 10:03 ` [RFC PATCH v4 1/3] tracing/events: Fix wrong sample output by storing array length instead of size He Kuang
2015-07-17 14:32 ` Steven Rostedt
2015-07-17 17:24 ` Sara Rostedt
2015-07-17 18:13 ` Steven Rostedt
2015-07-23 19:36 ` Alex Bennée
2015-07-10 10:03 ` [RFC PATCH v4 2/3] tools lib traceevent: Add function to get dynamic arrays length He Kuang
2015-07-10 10:03 ` [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event He Kuang
2015-07-10 22:10 ` Alexei Starovoitov
2015-07-13 4:36 ` He Kuang
2015-07-13 13:52 ` Namhyung Kim
2015-07-13 14:01 ` pi3orama
2015-07-13 14:09 ` Namhyung Kim
2015-07-13 14:29 ` pi3orama
2015-07-14 1:43 ` Alexei Starovoitov
2015-07-14 11:54 ` He Kuang
2015-07-17 4:11 ` Alexei Starovoitov
2015-07-17 4:14 ` Wangnan (F)
2015-07-17 4:27 ` Alexei Starovoitov
2015-07-23 11:54 ` He Kuang
2015-07-23 20:49 ` llvm bpf debug info. " Alexei Starovoitov
2015-07-24 3:20 ` Alexei Starovoitov
2015-07-24 4:16 ` He Kuang
2015-07-25 10:04 ` He Kuang
2015-07-28 2:18 ` Alexei Starovoitov
2015-07-29 9:38 ` He Kuang
2015-07-29 17:13 ` Alexei Starovoitov
2015-07-29 20:00 ` pi3orama
2015-07-29 22:20 ` Alexei Starovoitov
2015-07-31 10:18 ` Wangnan (F)
2015-07-31 10:20 ` [LLVM PATCH] BPF: add FRAMEADDR support Wang Nan
2015-07-31 10:21 ` [LLVM CLANG PATCH] BPF: add __builtin_bpf_typeid() Wang Nan
2015-07-31 10:48 ` llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event pi3orama
2015-08-03 19:44 ` Alexei Starovoitov
2015-08-04 9:01 ` Cc llvmdev: " Wangnan (F)
2015-08-05 1:58 ` Wangnan (F)
2015-08-05 2:05 ` Wangnan (F)
2015-08-05 6:51 ` Wangnan (F) [this message]
2015-08-05 7:11 ` [LLVMdev] " Alexei Starovoitov
2015-08-05 8:28 ` Wangnan (F)
2015-08-06 3:22 ` [llvm-dev] " Alexei Starovoitov
2015-08-06 4:35 ` Wangnan (F)
2015-08-06 6:55 ` Alexei Starovoitov
2015-08-12 2:34 ` Wangnan (F)
2015-08-12 4:57 ` [llvm-dev] " Alexei Starovoitov
2015-08-12 5:28 ` Wangnan (F)
2015-08-12 13:15 ` Brenden Blanco
2015-08-13 6:24 ` Wangnan (F)
2015-08-05 8:59 ` [LLVMdev] Cc llvmdev: " He Kuang
2015-08-06 3:41 ` [llvm-dev] " Alexei Starovoitov
2015-08-06 4:31 ` Wangnan (F)
2015-08-06 6:50 ` Alexei Starovoitov
2015-07-13 8:29 ` Peter Zijlstra
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=55C1B254.5030801@huawei.com \
--to=wangnan0@huawei.com \
--cc=ast@plumgrid.com \
--cc=hekuang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm-dev@lists.llvm.org \
--cc=pi3orama@163.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).