Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751646AbbGaKTY (ORCPT ); Fri, 31 Jul 2015 06:19:24 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:32852 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbbGaKTW (ORCPT ); Fri, 31 Jul 2015 06:19:22 -0400 Message-ID: <55BB4B8A.5000207@huawei.com> Date: Fri, 31 Jul 2015 18:18:50 +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> In-Reply-To: <55B909B2.2080606@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: 4314 Lines: 138 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 > search it in dwarf. Please take a look how to add such builtin. > There are few similar builtins that deal with exception handling > and need type info. May be they can be reused. Like: > int_eh_typeid_for and int_eh_dwarf_cfa > Hi Alexei, I have tested int_eh_dwarf_cfa and int_eh_typeid_for. By implementing ISD::FRAMEADDR support in LLVM BPF backend users are allowed to fetch frame address R11. __builtin_frame_addr(0) and __builtin_dwarf_cfa() will be enabled. By emitting llvm.eh_typeid_for in clang we can utilize it go generate an unique ID from a pointer of user defined type. However, we can't use pointer of local variables. I attach a sample program and the resuling asm output at the bottom of this mail. Looks like llvm.eh_typeid_for meets our goal further. However, currently it is still ugly: 1. llvm.eh_typeid_for can be used on global variables only. So for each output structure we have to define a global varable. 2. We still need to find a way to connect the fetchd typeid with DWARF info. Inserting that ID into DWARF may workable? 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 (http://llvm.org/git/clang.git f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git c8ccd78d31d4949fa1c14e954ccb06253e18cf37) <44> DW_AT_byte_size : 8 <45> DW_AT_decl_file : 1 <46> DW_AT_decl_line : 4 <2><47>: Abbrev Number: 4 (DW_TAG_member) <48> DW_AT_name : (indirect string, offset: 0x0): clang version 3.8.0 (http://llvm.org/git/clang.git f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git c8ccd78d31d4949fa1c14e954ccb06253e18cf37) <4c> DW_AT_type : <0x60> <50> DW_AT_decl_file : 1 <51> DW_AT_decl_line : 5 <52> DW_AT_data_member_location: 0 <2><53>: Abbrev Number: 4 (DW_TAG_member) <54> DW_AT_name : (indirect string, offset: 0x0): clang version 3.8.0 (http://llvm.org/git/clang.git f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git c8ccd78d31d4949fa1c14e954ccb06253e18cf37) <58> DW_AT_type : <0x60> <5c> DW_AT_decl_file : 1 <5d> DW_AT_decl_line : 6 <5e> DW_AT_data_member_location: 4 ... The DW_AT_name is missing. 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. Following is the sample code and resuling ASM: ======================================================== static int (*test_func)(unsigned long) = (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; test_func((void*)&var_a - __builtin_dwarf_cfa()); test_func(__builtin_bpf_typeid(&__str_my_str)); test_func(__builtin_bpf_typeid(&__str_my_str2)); return 0; } ==================== the resuling asm code ============= .text .globl func .align 8 func: # @func # BB#0: # %entry mov r1, r10 addi r1, -8 sub r1, r11 call 4660 mov r1, 1 call 4660 mov r1, 2 call 4660 mov r0, 0 ret .comm __str_my_str,8,4 # @__str_my_str .comm __str_my_str2,12,4 # @__str_my_str2 -- 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/