Thank you for your reply.
Add He Kuang to CC list.
On 2015/8/12 21:15, Brenden Blanco wrote:
Hi Wangnan, I've been authoring the BCC development, so I'll answer
those specific questions.
Could you please give us further information about your clang rewriter?
I guess you need a new .so when
Thank you for your reply.
Add He Kuang to CC list.
On 2015/8/12 21:15, Brenden Blanco wrote:
Hi Wangnan, I've been authoring the BCC development, so I'll answer
those specific questions.
Could you please give us further information about your clang rewriter?
I guess you need a new .so when
Hi Wangnan, I've been authoring the BCC development, so I'll answer
those specific questions.
>
>
> Could you please give us further information about your clang rewriter?
> I guess you need a new .so when injecting those code into kernel?
The rewriter runs all of its passes in a single process,
Hi Wangnan, I've been authoring the BCC development, so I'll answer
those specific questions.
Could you please give us further information about your clang rewriter?
I guess you need a new .so when injecting those code into kernel?
The rewriter runs all of its passes in a single process,
On 2015/8/12 12:57, Alexei Starovoitov wrote:
On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote:
Think about a program like this:
struct strA { int a; }
struct strB { int b; }
int func() {
struct strA a;
struct strB b;
a.a = 1;
b.b = 2;
On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote:
>
> Think about a program like this:
>
> struct strA { int a; }
> struct strB { int b; }
> int func() {
> struct strA a;
> struct strB b;
>
> a.a = 1;
> b.b = 2;
> bpf_output(gettype(a), );
>
On 2015/8/4 3:44, Alexei Starovoitov wrote:
[SNIP]
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.
[SNIP]
patch 2:
do we really need to hack clang?
Can you just define a function that aliases to intrinsic,
On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote:
Think about a program like this:
struct strA { int a; }
struct strB { int b; }
int func() {
struct strA a;
struct strB b;
a.a = 1;
b.b = 2;
bpf_output(gettype(a), a);
bpf_output(gettype(b), b);
On 2015/8/4 3:44, Alexei Starovoitov wrote:
[SNIP]
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.
[SNIP]
patch 2:
do we really need to hack clang?
Can you just define a function that aliases to intrinsic,
On 2015/8/12 12:57, Alexei Starovoitov wrote:
On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote:
Think about a program like this:
struct strA { int a; }
struct strB { int b; }
int func() {
struct strA a;
struct strB b;
a.a = 1;
b.b = 2;
On Thu, Aug 06, 2015 at 12:35:30PM +0800, Wangnan (F) wrote:
>
>
> On 2015/8/6 11:22, Alexei Starovoitov wrote:
> >On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
> >>It doesn't work for me at first since in my llvm there's only
> >>llvm.bpf.load.*.
> >>
> >>I think llvm.bpf.store.*
On Thu, Aug 06, 2015 at 12:31:26PM +0800, Wangnan (F) wrote:
>
>
> What about hacking ELF binary in memory?
>
> 1. load the object into memory;
> 2. twist the machine code to EM_X86_64;
> 3. load it using elf_begin;
> 4. return the twested elf memory image using libdwfl's find_elf callback.
>
On Thu, Aug 06, 2015 at 12:35:30PM +0800, Wangnan (F) wrote:
On 2015/8/6 11:22, Alexei Starovoitov wrote:
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
It doesn't work for me at first since in my llvm there's only
llvm.bpf.load.*.
I think llvm.bpf.store.* belone to some
On Thu, Aug 06, 2015 at 12:31:26PM +0800, Wangnan (F) wrote:
What about hacking ELF binary in memory?
1. load the object into memory;
2. twist the machine code to EM_X86_64;
3. load it using elf_begin;
4. return the twested elf memory image using libdwfl's find_elf callback.
Then
On 2015/8/6 11:22, Alexei Starovoitov wrote:
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
It doesn't work for me at first since in my llvm there's only
llvm.bpf.load.*.
I think llvm.bpf.store.* belone to some patches you haven't posted yet?
nope. only loads have special
On 2015/8/6 11:41, Alexei Starovoitov wrote:
On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote:
Hi, Alexei
On 2015/7/30 1:13, Alexei Starovoitov wrote:
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote:
> Hi, Alexei
>
> On 2015/7/30 1:13, Alexei Starovoitov wrote:
> >On 7/29/15 2:38 AM, He Kuang wrote:
> >>Hi, Alexei
> >>
> >>On 2015/7/28 10:18, Alexei Starovoitov wrote:
> >>>On 7/25/15 3:04 AM, He Kuang wrote:
> I noticed that for
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
>
> It doesn't work for me at first since in my llvm there's only
> llvm.bpf.load.*.
>
> I think llvm.bpf.store.* belone to some patches you haven't posted yet?
nope. only loads have special instructions ld_abs/ld_ind
which are
Hi, Alexei
On 2015/7/30 1:13, Alexei Starovoitov wrote:
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no
On 2015/8/5 15:11, Alexei Starovoitov wrote:
On 8/4/15 11:51 PM, Wangnan (F) wrote:
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
On 8/4/15 11:51 PM, Wangnan (F) wrote:
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
On 2015/8/5 10:05, Wangnan (F) wrote:
Send again since llvmdev is moved to llvm-...@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
On 2015/8/5 10:05, Wangnan (F) wrote:
Send again since llvmdev is moved to llvm-...@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
On 8/4/15 11:51 PM, Wangnan (F) wrote:
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
On 2015/8/5 15:11, Alexei Starovoitov wrote:
On 8/4/15 11:51 PM, Wangnan (F) wrote:
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
Hi, Alexei
On 2015/7/30 1:13, Alexei Starovoitov wrote:
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no
On 2015/8/6 11:22, Alexei Starovoitov wrote:
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
It doesn't work for me at first since in my llvm there's only
llvm.bpf.load.*.
I think llvm.bpf.store.* belone to some patches you haven't posted yet?
nope. only loads have special
On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote:
Hi, Alexei
On 2015/7/30 1:13, Alexei Starovoitov wrote:
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
It doesn't work for me at first since in my llvm there's only
llvm.bpf.load.*.
I think llvm.bpf.store.* belone to some patches you haven't posted yet?
nope. only loads have special instructions ld_abs/ld_ind
which are represented
On 2015/8/6 11:41, Alexei Starovoitov wrote:
On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote:
Hi, Alexei
On 2015/7/30 1:13, Alexei Starovoitov wrote:
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
Send again since llvmdev is moved to llvm-...@lists.llvm.org
On 2015/8/5 9:58, Wangnan (F) wrote:
On 2015/8/4 17:01, Wangnan (F) wrote:
For people who in llvmdev:
This mail is belong to a thread in linux kernel mailing list, the
first message
can be retrived from:
On 2015/8/4 17:01, Wangnan (F) wrote:
For people who in llvmdev:
This mail is belong to a thread in linux kernel mailing list, the
first message
can be retrived from:
http://lkml.kernel.org/r/55b1535e.8090...@plumgrid.com
Our goal is to fild a way to make BPF program get an unique ID for
For people who in llvmdev:
This mail is belong to a thread in linux kernel mailing list, the first
message
can be retrived from:
http://lkml.kernel.org/r/55b1535e.8090...@plumgrid.com
Our goal is to fild a way to make BPF program get an unique ID for each type
so it can pass the ID to other
For people who in llvmdev:
This mail is belong to a thread in linux kernel mailing list, the first
message
can be retrived from:
http://lkml.kernel.org/r/55b1535e.8090...@plumgrid.com
Our goal is to fild a way to make BPF program get an unique ID for each type
so it can pass the ID to other
Send again since llvmdev is moved to llvm-...@lists.llvm.org
On 2015/8/5 9:58, Wangnan (F) wrote:
On 2015/8/4 17:01, Wangnan (F) wrote:
For people who in llvmdev:
This mail is belong to a thread in linux kernel mailing list, the
first message
can be retrived from:
On 2015/8/4 17:01, Wangnan (F) wrote:
For people who in llvmdev:
This mail is belong to a thread in linux kernel mailing list, the
first message
can be retrived from:
http://lkml.kernel.org/r/55b1535e.8090...@plumgrid.com
Our goal is to fild a way to make BPF program get an unique ID for
On 7/31/15 3:18 AM, Wangnan (F) wrote:
However with the newest llvm + clang the DWARF info is still incorrect:
$ objdump --dwarf=info ./out.o
...
<1><3f>: Abbrev Number: 3 (DW_TAG_structure_type)
<40> DW_AT_name: (indirect string, offset: 0x0): clang
version 3.8.0
On 7/31/15 3:18 AM, Wangnan (F) wrote:
However with the newest llvm + clang the DWARF info is still incorrect:
$ objdump --dwarf=info ./out.o
...
13f: Abbrev Number: 3 (DW_TAG_structure_type)
40 DW_AT_name: (indirect string, offset: 0x0): clang
version 3.8.0
Just for your information:
The buggy DW_AT_name seems to be a problem in assembler.
I built the C file using -S:
$ clang -target bpf -g -c -O2 test.c
Then in resuming test.s, replaced all BPF op by "nop";
Also adjust .file directive;
Then assemble the .s file using as:
$ as -c test.s -o
On 2015/7/30 1:13, Alexei Starovoitov wrote:
[SNIP]
probably both A and B won't really work when programs get bigger
and optimizations will start moving lines around.
the builtin_dwarf_type idea is actually quite interesting.
Potentially that builtin can stringify type name and later we can
On 2015/7/30 1:13, Alexei Starovoitov wrote:
[SNIP]
probably both A and B won't really work when programs get bigger
and optimizations will start moving lines around.
the builtin_dwarf_type idea is actually quite interesting.
Potentially that builtin can stringify type name and later we can
Just for your information:
The buggy DW_AT_name seems to be a problem in assembler.
I built the C file using -S:
$ clang -target bpf -g -c -O2 test.c
Then in resuming test.s, replaced all BPF op by nop;
Also adjust .file directive;
Then assemble the .s file using as:
$ as -c test.s -o
On 7/29/15 1:00 PM, pi3orama wrote:
I was wondering if you could give us a hint on adding BPF specific builtins?
Doesn't like other machines, currently there's no Builtins.def for BPF to hold
builtins for that specific target. If we start creating such builtins, we can
bring
more there. One
发自我的 iPhone
> 在 2015年7月30日，上午1:13，Alexei Starovoitov 写道：
>
>> On 7/29/15 2:38 AM, He Kuang wrote:
>> Hi, Alexei
>>
>>> On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no 'Addend' info in bpf elf
file(64bit). I think there must be
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no 'Addend' info in bpf elf
file(64bit). I think there must be something wrong in the process
of .s ->
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no 'Addend' info in bpf elf
file(64bit). I think there must be
On 7/29/15 1:00 PM, pi3orama wrote:
I was wondering if you could give us a hint on adding BPF specific builtins?
Doesn't like other machines, currently there's no Builtins.def for BPF to hold
builtins for that specific target. If we start creating such builtins, we can
bring
more there. One
发自我的 iPhone
在 2015年7月30日，上午1:13，Alexei Starovoitov a...@plumgrid.com 写道：
On 7/29/15 2:38 AM, He Kuang wrote:
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the
Hi, Alexei
On 2015/7/28 10:18, Alexei Starovoitov wrote:
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no 'Addend' info in bpf elf
file(64bit). I think there must be something wrong in the process
of .s -
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no 'Addend' info in bpf elf
file(64bit). I think there must be something wrong in the process
of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out
On 7/25/15 3:04 AM, He Kuang wrote:
I noticed that for 64-bit elf format, the reloc sections have
'Addend' in the entry, but there's no 'Addend' info in bpf elf
file(64bit). I think there must be something wrong in the process
of .s - .o, which related to 64bit/32bit. Anyway, we can parse out
Hi, Alexei
On 2015/7/24 12:16, He Kuang wrote:
Hi, Alexei
On 2015/7/24 11:20, Alexei Starovoitov wrote:
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your
Hi, Alexei
On 2015/7/24 12:16, He Kuang wrote:
Hi, Alexei
On 2015/7/24 11:20, Alexei Starovoitov wrote:
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your
Hi, Alexei
On 2015/7/24 11:20, Alexei Starovoitov wrote:
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h
thanks! yes. it was missing.
and
Hi, Alexi
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h
and fix some unhandeled switch can make llc output debug_info,
but important information is missing in the result:
Hi, Alexi
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h
and fix some unhandeled switch can make llc output debug_info,
but important information is missing in the result:
Hi, Alexei
On 2015/7/24 11:20, Alexei Starovoitov wrote:
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h
thanks! yes. it was missing.
and
On 7/16/15 9:14 PM, Wangnan (F) wrote:
On 2015/7/17 12:11, Alexei Starovoitov wrote:
On 7/14/15 4:54 AM, He Kuang wrote:
I'm not sure llvm generates proper dwarf along with bpf code (I didn't
test that part. If there are any issues they should be fixable. If you
can prepapre a patch for llvm
On 2015/7/17 12:11, Alexei Starovoitov wrote:
On 7/14/15 4:54 AM, He Kuang wrote:
I'm not sure llvm generates proper dwarf along with bpf code (I didn't
test that part. If there are any issues they should be fixable. If you
can prepapre a patch for llvm that would be even better :)
I found
On 7/14/15 4:54 AM, He Kuang wrote:
I'm not sure llvm generates proper dwarf along with bpf code (I didn't
test that part. If there are any issues they should be fixable. If you
can prepapre a patch for llvm that would be even better :)
I found objdump can't get dwarf info from bpf object
On 2015/7/17 12:11, Alexei Starovoitov wrote:
On 7/14/15 4:54 AM, He Kuang wrote:
I'm not sure llvm generates proper dwarf along with bpf code (I didn't
test that part. If there are any issues they should be fixable. If you
can prepapre a patch for llvm that would be even better :)
I found
On 7/14/15 4:54 AM, He Kuang wrote:
I'm not sure llvm generates proper dwarf along with bpf code (I didn't
test that part. If there are any issues they should be fixable. If you
can prepapre a patch for llvm that would be even better :)
I found objdump can't get dwarf info from bpf object
On 7/16/15 9:14 PM, Wangnan (F) wrote:
On 2015/7/17 12:11, Alexei Starovoitov wrote:
On 7/14/15 4:54 AM, He Kuang wrote:
I'm not sure llvm generates proper dwarf along with bpf code (I didn't
test that part. If there are any issues they should be fixable. If you
can prepapre a patch for llvm
Hi, Alexei
On 2015/7/14 9:43, Alexei Starovoitov wrote:
On 7/13/15 7:29 AM, pi3orama wrote:
I was thinking about providing custom event formats for each bpf
>>>program (if needed). The event format definitions might be in a
>>>specific directory or a bpf object itself. Then perf can read
Hi, Alexei
On 2015/7/14 9:43, Alexei Starovoitov wrote:
On 7/13/15 7:29 AM, pi3orama wrote:
I was thinking about providing custom event formats for each bpf
program (if needed). The event format definitions might be in a
specific directory or a bpf object itself. Then perf can read those
On 7/13/15 7:29 AM, pi3orama wrote:
I was thinking about providing custom event formats for each bpf
>>>program (if needed). The event format definitions might be in a
>>>specific directory or a bpf object itself. Then perf can read those
>>>formats and print the output data according to the
发自我的 iPhone
> 在 2015年7月13日，下午10:09，Namhyung Kim 写道：
>
>> On Mon, Jul 13, 2015 at 10:01:26PM +0800, pi3orama wrote:
>>
>>
>> 发自我的 iPhone
>>
>>> 在 2015年7月13日，下午9:52，Namhyung Kim 写道：
>>>
>>> Hi,
>>>
On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
hi, Alexei
>>
On Mon, Jul 13, 2015 at 10:01:26PM +0800, pi3orama wrote:
>
>
> 发自我的 iPhone
>
> > 在 2015年7月13日，下午9:52，Namhyung Kim 写道：
> >
> > Hi,
> >
> >> On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
> >> hi, Alexei
> >>
> >>> On 2015/7/11 6:10, Alexei Starovoitov wrote:
> On 7/10/15
发自我的 iPhone
> 在 2015年7月13日，下午9:52，Namhyung Kim 写道：
>
> Hi,
>
>> On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
>> hi, Alexei
>>
>>> On 2015/7/11 6:10, Alexei Starovoitov wrote:
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record
Hi,
On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
> hi, Alexei
>
> On 2015/7/11 6:10, Alexei Starovoitov wrote:
> >On 7/10/15 3:03 AM, He Kuang wrote:
> >>There're scenarios that we need an eBPF program to record not only
> >>kprobe point args, but also the PMU counters, time
On Fri, Jul 10, 2015 at 10:03:07AM +, He Kuang wrote:
> include/trace/events/bpf.h | 30 ++
> include/uapi/linux/bpf.h | 7 +++
> kernel/trace/bpf_trace.c | 23 +++
> samples/bpf/bpf_helpers.h | 2 ++
> 4 files changed, 62
Hi,
On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
hi, Alexei
On 2015/7/11 6:10, Alexei Starovoitov wrote:
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
On Mon, Jul 13, 2015 at 10:01:26PM +0800, pi3orama wrote:
发自我的 iPhone
在 2015年7月13日，下午9:52，Namhyung Kim namhy...@kernel.org 写道：
Hi,
On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
hi, Alexei
On 2015/7/11 6:10, Alexei Starovoitov wrote:
On 7/10/15 3:03 AM, He
发自我的 iPhone
在 2015年7月13日，下午10:09，Namhyung Kim namhy...@kernel.org 写道：
On Mon, Jul 13, 2015 at 10:01:26PM +0800, pi3orama wrote:
发自我的 iPhone
在 2015年7月13日，下午9:52，Namhyung Kim namhy...@kernel.org 写道：
Hi,
On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
hi, Alexei
On
发自我的 iPhone
在 2015年7月13日，下午9:52，Namhyung Kim namhy...@kernel.org 写道：
Hi,
On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
hi, Alexei
On 2015/7/11 6:10, Alexei Starovoitov wrote:
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record
On 7/13/15 7:29 AM, pi3orama wrote:
I was thinking about providing custom event formats for each bpf
program (if needed). The event format definitions might be in a
specific directory or a bpf object itself. Then perf can read those
formats and print the output data according to the formats.
On Fri, Jul 10, 2015 at 10:03:07AM +, He Kuang wrote:
include/trace/events/bpf.h | 30 ++
include/uapi/linux/bpf.h | 7 +++
kernel/trace/bpf_trace.c | 23 +++
samples/bpf/bpf_helpers.h | 2 ++
4 files changed, 62 insertions(+)
hi, Alexei
On 2015/7/11 6:10, Alexei Starovoitov wrote:
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other
hi, Alexei
On 2015/7/11 6:10, Alexei Starovoitov wrote:
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.
This patch adds a new
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.
This patch adds a new trace event to establish
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.
This patch adds a new trace event to establish
On 7/10/15 3:03 AM, He Kuang wrote:
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.
This patch adds a new
88 matches
Mail list logo
