From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752688AbbGaKs4 (ORCPT ); Fri, 31 Jul 2015 06:48:56 -0400 Received: from m12-17.163.com ([220.181.12.17]:55283 "EHLO m12-17.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752049AbbGaKsz convert rfc822-to-8bit (ORCPT ); Fri, 31 Jul 2015 06:48:55 -0400 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event From: pi3orama X-Mailer: iPhone Mail (12H143) In-Reply-To: <55BB4B8A.5000207@huawei.com> Date: Fri, 31 Jul 2015 18:48:43 +0800 Cc: Alexei Starovoitov , He Kuang , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: <61AC0878-0C94-4C30-84DC-3F0982AFB1EC@163.com> 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> To: "Wangnan (F)" X-CM-TRANSID: EcCowAD3PhqIUrtVDgvtAA--.40981S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxCr4DXFWfuF18trWDCr4fuFg_yoWrCF43pF WkuasakrW8ta4kKw1fAr4Fqr1S9r4ktF4kJryrA34qyF9xAasrtF4Utw43Cry5CFnrCF4S vFWUt3s7Aw1DXrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUOzsUUUUU= X-Originating-IP: [117.136.0.57] X-CM-SenderInfo: lslt02xdpdqiywtou0bp/1tbishtIQFUL3Nj9FgABsR Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 test.o Then check dwarf info using objdump: $ objdump --dwarf=info test.o DW_AT_name looks all correct. Thank you. 发自我的 iPhone > 在 2015年7月31日，下午6:18，Wangnan (F) 写道： > > > > 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 > >