From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751944AbbHEIfK (ORCPT ); Wed, 5 Aug 2015 04:35:10 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:24183 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751227AbbHEIfH (ORCPT ); Wed, 5 Aug 2015 04:35:07 -0400 Message-ID: <55C1C91D.5080007@huawei.com> Date: Wed, 5 Aug 2015 16:28:13 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexei Starovoitov , He Kuang , pi3orama CC: , "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 References: <1436522587-136825-1-git-send-email-hekuang@huawei.com> <1436522587-136825-4-git-send-email-hekuang@huawei.com> <55A042DC.6030809@plumgrid.com> <55A3404B.6020904@huawei.com> <20150713135223.GB9917@danjae.kornet> <4D441676-21A7-46EE-AAB0-EB529D408082@163.com> <20150713140915.GD9917@danjae.kornet> <55A46928.9090708@plumgrid.com> <55A4F869.1020705@huawei.com> <55A88085.8090407@plumgrid.com> <55A88137.7020609@huawei.com> <55A88449.3030008@plumgrid.com> <55B0D5FC.6050406@huawei.com> <55B1535E.8090406@plumgrid.com> <55B1AEE9.1080207@plumgrid.com> <55B1BC03.9020708@huawei.com> <55B35F42.70803@huawei.com> <55B6E685.30905@plumgrid.com> <55B89F04.5030304@huawei.com> <55B909B2.2080606@plumgrid.com> <55BB4B8A.5000207@huawei.com> <55BFC4A0.9060100@plumgrid.com> <55C07F5B.6030107@huawei.com> <55C16DC7.70408@huawei.com> <55C16F53.3070604@huawei.com> <55C1B254.5030801@huawei.com> <55C1B717.60501@plumgrid.com> In-Reply-To: <55C1B717.60501@plumgrid.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.55C1C937.0097,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9d127276c8bf253280e6073341d7478e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.