Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755395AbbHCToh (ORCPT ); Mon, 3 Aug 2015 15:44:37 -0400 Received: from mail-yk0-f180.google.com ([209.85.160.180]:33355 "EHLO mail-yk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754315AbbHCTof (ORCPT ); Mon, 3 Aug 2015 15:44:35 -0400 Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event To: "Wangnan (F)" , He Kuang , pi3orama 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> Cc: "linux-kernel@vger.kernel.org" From: Alexei Starovoitov Message-ID: <55BFC4A0.9060100@plumgrid.com> Date: Mon, 3 Aug 2015 12:44:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55BB4B8A.5000207@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3667 Lines: 103 On 7/31/15 3:18 AM, Wangnan (F) wrote: > > 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. 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. 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. > 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? 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. btw, for any deep llvm stuff you may need to move the thread to llvmdev. May be folks there will have other ideas. -- 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/