Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753709AbbHLCfR (ORCPT ); Tue, 11 Aug 2015 22:35:17 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:58087 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753411AbbHLCfP (ORCPT ); Tue, 11 Aug 2015 22:35:15 -0400 Message-ID: <55CAB0C3.40805@huawei.com> Date: Wed, 12 Aug 2015 10:34:43 +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: 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> In-Reply-To: <55BFC4A0.9060100@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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2799 Lines: 83 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, > 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. Hi Alexei, By two weeks researching, I have to give you a sad answer that: target specific intrinsic is not work. I tried target specific intrinsic. However, LLVM isolates backend and frontend, and there's no way to pass language level type information to backend code. 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); return 0; } BPF backend can't (and needn't) tell the difference between local variables a and b in theory. In LLVM implementation, it filters type information out using ComputeValueVTs(). Please have a look at SelectionDAGBuilder::visitIntrinsicCall in lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp and SelectionDAGBuilder::visitTargetIntrinsic in the same file. in visitTargetIntrinsic, ComputeValueVTs acts as a barrier which strips type information out from CallInst ("I"), and leave SDValue and SDVTList ("Ops" and "VTs") to target code. SDValue and SDVTList are wrappers of EVT and MVT, all information we concern won't be passed here. I think now we have 2 choices: 1. Hacking into clang, implement target specific builtin function. Now I have worked out a ugly but workable patch which setup a builtin function: __builtin_bpf_typeid(), which accepts local or global variable then returns different constant for different types. 2. Implementing an LLVM intrinsic call (llvm.typeid), make it be processed in visitIntrinsicCall(). I think we can get something useful if it is processed with that function. The next thing should be generating debug information to map type and constants which issued by __builtin_bpf_typeid() or llvm.typeid. Now we have a crazy idea that, if we limit the name of the structure to 8 bytes, we can insert the name into a u64, then there would be no need to consider type information in DWARF. For example, in the above sample code, gettype(a) will issue 0x0000000041727473 because its type is "strA". What do you think? 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/