Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1200351 > unrolled thread
| Started by | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| First post | 2015-08-05 04:00 +0200 |
| Last post | 2015-08-06 09:00 +0200 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-05 04:00 +0200
Re: Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-05 04:10 +0200
Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-05 09:00 +0200
Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Alexei Starovoitov <ast@plumgrid.com> - 2015-08-05 09:20 +0200
Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-05 10:40 +0200
Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2015-08-06 05:30 +0200
Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event "Wangnan (F)" <wangnan0@huawei.com> - 2015-08-06 06:40 +0200
Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2015-08-06 09:00 +0200
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Date | 2015-08-05 04:00 +0200 |
| Subject | Re: Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event |
| Message-ID | <pTW9P-3AW-1@gated-at.bofh.it> |
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.8090406@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 part of kernel, then we can retrive the
> type and
> decode the structure using DWARF information. Currently we have two
> problem
> needs to solve:
>
> 1. Dwarf information generated by BPF backend lost all DW_AT_name field;
>
> 2. How to get typeid from local variable? I tried llvm.eh_typeid_for
> but it support global variable only.
>
> Following is my response to Alexei.
>
> 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.
>>
>>> struct my_str {
>>> int x;
>>> int y;
>>> };
>>> struct my_str __str_my_str;
>>>
>>> struct my_str2 {
>>> int x;
>>> int y;
>>> int z;
>>> };
>>> struct my_str2 __str_my_str2;
>>>
>>> test_func(__builtin_bpf_typeid(&__str_my_str));
>>> test_func(__builtin_bpf_typeid(&__str_my_str2));
>>> mov r1, 1
>>> call 4660
>>> mov r1, 2
>>> call 4660
>>
>> this part looks good. I think it's usable.
>>
>> > 1. llvm.eh_typeid_for can be used on global variables only. So for
>> each
>> > output
>> > structure we have to define a global varable.
>>
>> why? I think it should work with local pointers as well.
>>
>
> It is defined by LLVM, in lib/CodeGen/Analysis.cpp:
>
> /// ExtractTypeInfo - Returns the type info, possibly bitcast, encoded
> in V.
> GlobalValue *llvm::ExtractTypeInfo(Value *V) {
> ...
> assert((GV || isa<ConstantPointerNull>(V)) &&
> "TypeInfo must be a global variable or NULL"); <-- we can
> use only constant pointers
> return GV;
> }
>
> So from llvm::Intrinsic::eh_typeid_for we can get type of global
> variables only.
>
> We may need a new intrinsic for that.
>
>
>> > 2. We still need to find a way to connect the fetchd typeid with DWARF
>> > info.
>> > Inserting that ID into DWARF may workable?
>>
>> hmm, that id should be the same id we're seeing in dwarf, right?
>
> There's no 'typeid' field in dwarf originally. I'm still looking for a
> way
> to inject this ID into dwarf infromation.
>
>> I think it's used in exception handling which is reusing some of
>> the dwarf stuff for this, so the must be a way to connect that id
>> to actual type info. Though last time I looked at EH was
>> during g++ hacking days. No idea how llvm does it exactly, but
>> I'm assuming the logic for rtti should be similar.
>>
>
> I'm not sure whether RTTI use dwarf to deduce type information. I
> think not,
> because dwarf infos can be stripped out.
>
Hi Alexei,
Just found that llvm::Intrinsic::eh_typeid_for is function specific. ID
of same type in
different functions may be different. Here is an example:
static int (*bpf_output_event)(unsigned long, void *buf, int size) =
(void *) 0x1234;
struct my_str {
int x;
int y;
};
struct my_str __str_my_str;
struct my_str2 {
int x;
int y;
int z;
};
struct my_str2 __str_my_str2;
int func(int *ctx)
{
struct my_str var_a;
struct my_str2 var_b;
bpf_output_event(__builtin_bpf_typeid(&__str_my_str), &var_a,
sizeof(var_a));
bpf_output_event(__builtin_bpf_typeid(&__str_my_str2), &var_b,
sizeof(var_b));
return 0;
}
int func2(int *ctx)
{
struct my_str var_a;
struct my_str2 var_b;
/* change order here */
bpf_output_event(__builtin_bpf_typeid(&__str_my_str2), &var_b,
sizeof(var_b));
bpf_output_event(__builtin_bpf_typeid(&__str_my_str), &var_a,
sizeof(var_a))
return 0;
}
This program uses __builtin_bpf_typeid(llvm::Intrinsic::eh_typeid_for)
in func and func2
for same two types but in different order. We expect same type get same ID.
Compiled with:
$ clang -target bpf -S -O2 -c ./test_bpf_typeid.c
The result is:
.text
.globl func
.align 8
func: # @func
# BB#0: # %entry
mov r2, r10
addi r2, -8
mov r1, 1
mov r3, 8
call 4660
mov r2, r10
addi r2, -24
mov r1, 2
mov r3, 12
call 4660
mov r0, 0
ret
.globl func2
.align 8
func2: # @func2
# BB#0: # %entry
mov r2, r10
addi r2, -24
mov r1, 1 <--- we want 2 here.
mov r3, 12
call 4660
mov r2, r10
addi r2, -8
mov r1, 2 <--- we want 1 here.
mov r3, 8
call 4660
mov r0, 0
ret
.comm __str_my_str,8,4 # @__str_my_str
.comm __str_my_str2,12,4 # @__str_my_str2
Conclusion: llvm::Intrinsic::eh_typeid_for is not on the right direction...
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Date | 2015-08-05 04:10 +0200 |
| Message-ID | <pTWjx-41F-43@gated-at.bofh.it> |
| In reply to | #1200351 |
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 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.8090406@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 part of kernel, then we can retrive
>> the type and
>> decode the structure using DWARF information. Currently we have two
>> problem
>> needs to solve:
>>
>> 1. Dwarf information generated by BPF backend lost all DW_AT_name field;
>>
>> 2. How to get typeid from local variable? I tried llvm.eh_typeid_for
>> but it support global variable only.
>>
>> Following is my response to Alexei.
>>
>> 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.
>>>
>>>> struct my_str {
>>>> int x;
>>>> int y;
>>>> };
>>>> struct my_str __str_my_str;
>>>>
>>>> struct my_str2 {
>>>> int x;
>>>> int y;
>>>> int z;
>>>> };
>>>> struct my_str2 __str_my_str2;
>>>>
>>>> test_func(__builtin_bpf_typeid(&__str_my_str));
>>>> test_func(__builtin_bpf_typeid(&__str_my_str2));
>>>> mov r1, 1
>>>> call 4660
>>>> mov r1, 2
>>>> call 4660
>>>
>>> this part looks good. I think it's usable.
>>>
>>> > 1. llvm.eh_typeid_for can be used on global variables only. So for
>>> each
>>> > output
>>> > structure we have to define a global varable.
>>>
>>> why? I think it should work with local pointers as well.
>>>
>>
>> It is defined by LLVM, in lib/CodeGen/Analysis.cpp:
>>
>> /// ExtractTypeInfo - Returns the type info, possibly bitcast,
>> encoded in V.
>> GlobalValue *llvm::ExtractTypeInfo(Value *V) {
>> ...
>> assert((GV || isa<ConstantPointerNull>(V)) &&
>> "TypeInfo must be a global variable or NULL"); <-- we can
>> use only constant pointers
>> return GV;
>> }
>>
>> So from llvm::Intrinsic::eh_typeid_for we can get type of global
>> variables only.
>>
>> We may need a new intrinsic for that.
>>
>>
>>> > 2. We still need to find a way to connect the fetchd typeid with
>>> DWARF
>>> > info.
>>> > Inserting that ID into DWARF may workable?
>>>
>>> hmm, that id should be the same id we're seeing in dwarf, right?
>>
>> There's no 'typeid' field in dwarf originally. I'm still looking for
>> a way
>> to inject this ID into dwarf infromation.
>>
>>> I think it's used in exception handling which is reusing some of
>>> the dwarf stuff for this, so the must be a way to connect that id
>>> to actual type info. Though last time I looked at EH was
>>> during g++ hacking days. No idea how llvm does it exactly, but
>>> I'm assuming the logic for rtti should be similar.
>>>
>>
>> I'm not sure whether RTTI use dwarf to deduce type information. I
>> think not,
>> because dwarf infos can be stripped out.
>>
>
> Hi Alexei,
>
> Just found that llvm::Intrinsic::eh_typeid_for is function specific.
> ID of same type in
> different functions may be different. Here is an example:
>
> static int (*bpf_output_event)(unsigned long, void *buf, int size) =
> (void *) 0x1234;
>
> struct my_str {
> int x;
> int y;
> };
> struct my_str __str_my_str;
>
> struct my_str2 {
> int x;
> int y;
> int z;
> };
> struct my_str2 __str_my_str2;
>
> int func(int *ctx)
> {
> struct my_str var_a;
> struct my_str2 var_b;
> bpf_output_event(__builtin_bpf_typeid(&__str_my_str), &var_a,
> sizeof(var_a));
> bpf_output_event(__builtin_bpf_typeid(&__str_my_str2), &var_b,
> sizeof(var_b));
> return 0;
> }
>
> int func2(int *ctx)
> {
> struct my_str var_a;
> struct my_str2 var_b;
>
> /* change order here */
> bpf_output_event(__builtin_bpf_typeid(&__str_my_str2), &var_b,
> sizeof(var_b));
> bpf_output_event(__builtin_bpf_typeid(&__str_my_str), &var_a,
> sizeof(var_a))
> return 0;
> }
>
> This program uses __builtin_bpf_typeid(llvm::Intrinsic::eh_typeid_for)
> in func and func2
> for same two types but in different order. We expect same type get
> same ID.
>
> Compiled with:
>
> $ clang -target bpf -S -O2 -c ./test_bpf_typeid.c
>
> The result is:
>
> .text
> .globl func
> .align 8
> func: # @func
> # BB#0: # %entry
> mov r2, r10
> addi r2, -8
> mov r1, 1
> mov r3, 8
> call 4660
> mov r2, r10
> addi r2, -24
> mov r1, 2
> mov r3, 12
> call 4660
> mov r0, 0
> ret
>
> .globl func2
> .align 8
> func2: # @func2
> # BB#0: # %entry
> mov r2, r10
> addi r2, -24
> mov r1, 1 <--- we want 2 here.
> mov r3, 12
> call 4660
> mov r2, r10
> addi r2, -8
> mov r1, 2 <--- we want 1 here.
> mov r3, 8
> call 4660
> mov r0, 0
> ret
>
> .comm __str_my_str,8,4 # @__str_my_str
> .comm __str_my_str2,12,4 # @__str_my_str2
>
>
> Conclusion: llvm::Intrinsic::eh_typeid_for is not on the right
> direction...
>
> Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Date | 2015-08-05 09:00 +0200 |
| 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 |
| Message-ID | <pU0Qa-22l-17@gated-at.bofh.it> |
| In reply to | #1200356 |
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alexei Starovoitov <ast@plumgrid.com> |
|---|---|
| Date | 2015-08-05 09:20 +0200 |
| 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 |
| Message-ID | <pU19w-2FR-1@gated-at.bofh.it> |
| In reply to | #1200462 |
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
> .align 8
> func: # @func
> # BB#0: # %entry
> mov r1, 0
> mov r2, 0
> mov r3, 0
> call llvm.bpf.store.half
it didn't work because number and types of args were incompatible.
Every samples/bpf/sockex[0-9]_kern.c is using llvm.bpf.load.* intrinsics.
the typeid changing ids with order is surprising.
I think the assertion in ExtractTypeInfo() is not hard.
Just there were no such use cases. May be we can do something
similar to what LowerIntrinsicCall() does and lower it differently
in the backend.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Date | 2015-08-05 10:40 +0200 |
| 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 |
| Message-ID | <pU2oV-4nL-1@gated-at.bofh.it> |
| In reply to | #1200468 |
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 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
>
> it didn't work because number and types of args were incompatible.
> Every samples/bpf/sockex[0-9]_kern.c is using llvm.bpf.load.* intrinsics.
>
Make it work. Thank you.
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?
> the typeid changing ids with order is surprising.
> I think the assertion in ExtractTypeInfo() is not hard.
> Just there were no such use cases. May be we can do something
> similar to what LowerIntrinsicCall() does and lower it differently
> in the backend.
>
But in backend can we still get type information? I thought type is
meaningful in frontend only, and backend behaviors is unable to affect
DWARF generation, right?
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alexei Starovoitov <alexei.starovoitov@gmail.com> |
|---|---|
| Date | 2015-08-06 05:30 +0200 |
| Subject | Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event |
| Message-ID | <pUk2t-4Ik-5@gated-at.bofh.it> |
| In reply to | #1200528 |
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 by these intrinsics. stores, so far, are done via single bpf_store_bytes() helper function. > >the typeid changing ids with order is surprising. > >I think the assertion in ExtractTypeInfo() is not hard. > >Just there were no such use cases. May be we can do something > >similar to what LowerIntrinsicCall() does and lower it differently > >in the backend. > > > But in backend can we still get type information? I thought type is > meaningful in frontend only, and backend behaviors is unable to affect > DWARF generation, right? why do we need to affect type generation? we just need to know dwarf type id in the backend, so we can emit it as a constant. I still think lowering eh_typeid_for differently may work. Like instead of doing GV = ExtractTypeInfo(I.getArgOperand(0)) followed by getMachineFunction().getMMI().getTypeIDFor(GV) we can get dwarf type id from I.getArgOperand(0) if it's any pointer to struct type. I'm not familiar with dwarf handling part of llvm, but feels possible. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Date | 2015-08-06 06:40 +0200 |
| Subject | Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event |
| Message-ID | <pUl8d-6gt-3@gated-at.bofh.it> |
| In reply to | #1201408 |
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 instructions ld_abs/ld_ind
> which are represented by these intrinsics.
> stores, so far, are done via single bpf_store_bytes() helper function.
>
>>> the typeid changing ids with order is surprising.
>>> I think the assertion in ExtractTypeInfo() is not hard.
>>> Just there were no such use cases. May be we can do something
>>> similar to what LowerIntrinsicCall() does and lower it differently
>>> in the backend.
>>>
>> But in backend can we still get type information? I thought type is
>> meaningful in frontend only, and backend behaviors is unable to affect
>> DWARF generation, right?
> why do we need to affect type generation? we just need to know dwarf
> type id in the backend, so we can emit it as a constant.
> I still think lowering eh_typeid_for differently may work.
> Like instead of doing
> GV = ExtractTypeInfo(I.getArgOperand(0)) followed by
> getMachineFunction().getMMI().getTypeIDFor(GV)
> we can get dwarf type id from I.getArgOperand(0) if it's
> any pointer to struct type.
I have a bad news to tell:
#include <stdio.h>
struct my_str {
int x;
int y;
} __gv_my_str;
struct my_str __gv_my_str_;
struct my_str2 {
int x;
int y;
} __gv_my_str2;
int typeid(void *p) asm("llvm.eh.typeid.for");
int main()
{
printf("%d\n", typeid(&__gv_my_str));
printf("%d\n", typeid(&__gv_my_str_));
printf("%d\n", typeid(&__gv_my_str2));
return 0;
}
Compiled with clang into x86 executable, then:
$ ./a.out
3
2
1
See? I have two types but reported 3 IDs.
And here is the implementation of getTypeIDFor, in
lib/CodeGen/MachineModuleInfo.cpp:
unsigned MachineModuleInfo::getTypeIDFor(const GlobalValue *TI) {
for (unsigned i = 0, N = TypeInfos.size(); i != N; ++i)
if (TypeInfos[i] == TI) return i + 1;
TypeInfos.push_back(TI);
return TypeInfos.size();
}
It only checks value in a stupid way.
Now the dwarf side becomes clear (see my other response), but the
frontend may require
totally reconsidering.
Do you know someone in LLVM-dev who can help us?
Thank you.
> I'm not familiar with dwarf handling part of llvm, but feels possible.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alexei Starovoitov <alexei.starovoitov@gmail.com> |
|---|---|
| Date | 2015-08-06 09:00 +0200 |
| Subject | Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event |
| Message-ID | <pUnjI-1ck-9@gated-at.bofh.it> |
| In reply to | #1201424 |
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 patches you haven't posted yet?
> >nope. only loads have special instructions ld_abs/ld_ind
> >which are represented by these intrinsics.
> >stores, so far, are done via single bpf_store_bytes() helper function.
> >
> >>>the typeid changing ids with order is surprising.
> >>>I think the assertion in ExtractTypeInfo() is not hard.
> >>>Just there were no such use cases. May be we can do something
> >>>similar to what LowerIntrinsicCall() does and lower it differently
> >>>in the backend.
> >>>
> >>But in backend can we still get type information? I thought type is
> >>meaningful in frontend only, and backend behaviors is unable to affect
> >>DWARF generation, right?
> >why do we need to affect type generation? we just need to know dwarf
> >type id in the backend, so we can emit it as a constant.
> >I still think lowering eh_typeid_for differently may work.
> >Like instead of doing
> >GV = ExtractTypeInfo(I.getArgOperand(0)) followed by
> >getMachineFunction().getMMI().getTypeIDFor(GV)
> >we can get dwarf type id from I.getArgOperand(0) if it's
> >any pointer to struct type.
>
> I have a bad news to tell:
>
> #include <stdio.h>
> struct my_str {
> int x;
> int y;
> } __gv_my_str;
> struct my_str __gv_my_str_;
>
> struct my_str2 {
> int x;
> int y;
> } __gv_my_str2;
>
> int typeid(void *p) asm("llvm.eh.typeid.for");
>
> int main()
> {
> printf("%d\n", typeid(&__gv_my_str));
> printf("%d\n", typeid(&__gv_my_str_));
> printf("%d\n", typeid(&__gv_my_str2));
> return 0;
> }
>
> Compiled with clang into x86 executable, then:
>
> $ ./a.out
> 3
> 2
> 1
>
> See? I have two types but reported 3 IDs.
that's expected. We don't have to use default lowering
of typeid_for with getTypeIDFor. bpf backend specific
lowering can be different, though in this case it's odd
that id for __gv_my_str and __gv_my_str_ are different.
__gv_my_str and __gv_my_str2 should be different.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web