Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752994AbbGQE15 (ORCPT <rfc822;w@1wt.eu>);
	Fri, 17 Jul 2015 00:27:57 -0400
Received: from mail-pa0-f51.google.com ([209.85.220.51]:33788 "EHLO
	mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750849AbbGQE14 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 17 Jul 2015 00:27:56 -0400
Subject: Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to
 perf event
To: "Wangnan (F)" <wangnan0@huawei.com>, He Kuang <hekuang@huawei.com>,
        pi3orama <pi3orama@163.com>, Namhyung Kim <namhyung@kernel.org>
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>
 <B5145998-CD5C-4B1B-9A42-CD19691EF80B@163.com>
 <55A46928.9090708@plumgrid.com> <55A4F869.1020705@huawei.com>
 <55A88085.8090407@plumgrid.com> <55A88137.7020609@huawei.com>
Cc: "rostedt@goodmis.org" <rostedt@goodmis.org>,
        "masami.hiramatsu.pt@hitachi.com" <masami.hiramatsu.pt@hitachi.com>,
        "acme@kernel.org" <acme@kernel.org>,
        "a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "jolsa@kernel.org" <jolsa@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
From: Alexei Starovoitov <ast@plumgrid.com>
Message-ID: <55A88449.3030008@plumgrid.com>
Date: Thu, 16 Jul 2015 21:27:53 -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: <55A88137.7020609@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2602
Lines: 70

On 7/16/15 9:14 PM, Wangnan (F) wrote:
>
>
> On 2015/7/17 12:11, Alexei Starovoitov wrote:
>> On 7/14/15 4:54 AM, He Kuang wrote:
>>>> I'm not sure llvm generates proper dwarf along with bpf code (I didn't
>>>> test that part. If there are any issues they should be fixable. If you
>>>> can prepapre a patch for llvm that would be even better :)
>>>>
>>>
>>> I found objdump can't get dwarf info from bpf object file:
>>>
>>>    $ objdump --dwarf=info bpf.o
>>>    bpf.o: file format elf64-little
>>>
>>>    $ readelf -a bpf.o |grep debug_info
>>>    <EMPTY>
>>
>> yeah. looks like this part is not working.
>> Interesting that when I do: clang -O2 -target bpf a.c -g -S
>> there is some minimal debug info in the .s, but .o lacks
>> debuginfo completely. Digging further...
>
> Glad to see you start look at it. We are not familiar with LLVM, but I was
> told that LLVM has a clean structure and very easy to introduce new
> features.
> Could you please give us some hits on it so we can work together?

sure. that would be awesome.
In general llmv is very well documented:
http://llvm.org/docs/

In this particular case start with:
clang -O2 -emit-llvm -g a.c -S -o a.ll
in a.ll you'll see llvm bitcode with corresponding debug tags.
note debug info in llvm ir in general is not compatible between
releases. So clang and llc need to match very closely.

Then use:
llc -march=bpf -print-after-all a.ll
you'll see something like:
BB#0: derived from LLVM BB %0
	DBG_VALUE %R1, %noreg, !"a", <!16>; line no:6
	DBG_VALUE %R2, %noreg, !"b", <!16>; line no:6
	DBG_VALUE %R3, %noreg, !"c", <!16>; line no:6
	%R1<def> = MOV_ri 0
	%R2<def> = MOV_ri 3
	JAL <ga:@bar>, %R0<imp-def,dead>, %R1<imp-def,dead>, %R2<imp-def,dead>, 
%R3<imp-def,dead>, %R11<imp-use>, %R1<imp-use>, %R2<imp-use>, ...; 
dbg:a.c:8:2
	%R1<def> = MOV_ri 1; dbg:a.c:9:2

which means that debug info about line numbers and variable
names/types mapping to bpf registers was preserved all the way
till the last pass of the compiler.

It means that the problem is somewhere in 'machine code emitter'
in lib/Target/BPF/MCTargetDesc/*
Likely just some switch is saying to the rest of llvm infra that
this backend is not capable of emitting debug info.

btw, if you can implement 32-bit subregister support for the backend
it would be really awesome. Many programs will benefit and will
become faster.

--
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/