From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755117AbbG1CSs (ORCPT ); Mon, 27 Jul 2015 22:18:48 -0400 Received: from mail-yk0-f177.google.com ([209.85.160.177]:35638 "EHLO mail-yk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754483AbbG1CSr (ORCPT ); Mon, 27 Jul 2015 22:18:47 -0400 Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event To: He Kuang , "Wangnan (F)" , 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> Cc: "linux-kernel@vger.kernel.org" From: Alexei Starovoitov Message-ID: <55B6E685.30905@plumgrid.com> Date: Mon, 27 Jul 2015 19:18:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55B35F42.70803@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 On 7/25/15 3:04 AM, He Kuang wrote: > I noticed that for 64-bit elf format, the reloc sections have > 'Addend' in the entry, but there's no 'Addend' info in bpf elf > file(64bit). I think there must be something wrong in the process > of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the > AT_name now, DW_AT_LOCATION still missed and need your help. looks like objdump/llvm-dwarfdump can only read known EM, but that that shouldn't be the problem for your dwarf reader right? It should be able to recognize id-s of ELF::R_X86_64_* relo used right? As far as AT_location for testprog.c it seems there is no info for local variables because they were optimized away. With -O0 I see AT_location being emitted. Also line number info seems to be good in both cases. But in our case, we don't need this anyway, no? we need to see the types of structs mainly or you have some other use cases? I think line number info would be great to correlate the error reported by verifier into specific line in C.