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, 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
60 matches
Mail list logo