linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: He Kuang <hekuang@huawei.com>
To: Alexei Starovoitov <ast@plumgrid.com>,
	"Wangnan (F)" <wangnan0@huawei.com>, pi3orama <pi3orama@163.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<llvm-dev@lists.llvm.org>
Subject: Re: [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Date: Wed, 5 Aug 2015 16:59:01 +0800	[thread overview]
Message-ID: <55C1D055.2050205@huawei.com> (raw)
In-Reply-To: <55B909B2.2080606@plumgrid.com>

Hi, Alexei

On 2015/7/30 1:13, Alexei Starovoitov wrote:
> On 7/29/15 2:38 AM, He Kuang wrote:
>> Hi, Alexei
>>
>> On 2015/7/28 10:18, Alexei Starovoitov wrote:
>>> 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.
>>>

Another thing about DW_AT_name, we've already found that the name
string is stored indirectly and needs relocation which is
architecture specific, while the e_machine info in bpf obj file
is "unknown", both objdump and libdw cannot parse DW_AT_name
correctly.

Should we just use a known architeture for bpf object file
instead of "unknown"? If so, we can use the existing relocation
codes in libdw and get DIE name by simply invoking
dwarf_diename(). The drawback of this method is that, e.g. we
use "x86-64" instead, is hard to distinguish bpf obj file with
x86-64 elf file. Do you think this is ok?

Otherwise, for not touching libdw, we should reimplement the
relocation codes already in libdw for bpf elf file with "unknown"
machine info specially in perf. I wonder whether it is worth doing
this and what's your opinion?

Thank you.

>> index directly:
>>
>>    __bpf_trace_output_data(__builtin_dwarf_type(myvar_a), &myvar_a, size);
>>
>
> 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
>
>


  parent reply	other threads:[~2015-08-05  8:59 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 10:03 [RFC PATCH v4 0/3] Make eBPF programs output data to perf event He Kuang
2015-07-10 10:03 ` [RFC PATCH v4 1/3] tracing/events: Fix wrong sample output by storing array length instead of size He Kuang
2015-07-17 14:32   ` Steven Rostedt
2015-07-17 17:24     ` Sara Rostedt
2015-07-17 18:13     ` Steven Rostedt
2015-07-23 19:36       ` Alex Bennée
2015-07-10 10:03 ` [RFC PATCH v4 2/3] tools lib traceevent: Add function to get dynamic arrays length He Kuang
2015-07-10 10:03 ` [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event He Kuang
2015-07-10 22:10   ` Alexei Starovoitov
2015-07-13  4:36     ` He Kuang
2015-07-13 13:52       ` Namhyung Kim
2015-07-13 14:01         ` pi3orama
2015-07-13 14:09           ` Namhyung Kim
2015-07-13 14:29             ` pi3orama
2015-07-14  1:43               ` Alexei Starovoitov
2015-07-14 11:54                 ` He Kuang
2015-07-17  4:11                   ` Alexei Starovoitov
2015-07-17  4:14                     ` Wangnan (F)
2015-07-17  4:27                       ` Alexei Starovoitov
2015-07-23 11:54                         ` He Kuang
2015-07-23 20:49                           ` llvm bpf debug info. " Alexei Starovoitov
2015-07-24  3:20                             ` Alexei Starovoitov
2015-07-24  4:16                               ` He Kuang
2015-07-25 10:04                                 ` He Kuang
2015-07-28  2:18                                   ` Alexei Starovoitov
2015-07-29  9:38                                     ` He Kuang
2015-07-29 17:13                                       ` Alexei Starovoitov
2015-07-29 20:00                                         ` pi3orama
2015-07-29 22:20                                           ` Alexei Starovoitov
2015-07-31 10:18                                         ` Wangnan (F)
2015-07-31 10:20                                           ` [LLVM PATCH] BPF: add FRAMEADDR support Wang Nan
2015-07-31 10:21                                           ` [LLVM CLANG PATCH] BPF: add __builtin_bpf_typeid() Wang Nan
2015-07-31 10:48                                           ` llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event pi3orama
2015-08-03 19:44                                           ` Alexei Starovoitov
2015-08-04  9:01                                             ` Cc llvmdev: " Wangnan (F)
2015-08-05  1:58                                               ` Wangnan (F)
2015-08-05  2:05                                                 ` Wangnan (F)
2015-08-05  6:51                                                   ` [LLVMdev] " Wangnan (F)
2015-08-05  7:11                                                     ` Alexei Starovoitov
2015-08-05  8:28                                                       ` Wangnan (F)
2015-08-06  3:22                                                         ` [llvm-dev] " Alexei Starovoitov
2015-08-06  4:35                                                           ` Wangnan (F)
2015-08-06  6:55                                                             ` Alexei Starovoitov
2015-08-12  2:34                                             ` Wangnan (F)
2015-08-12  4:57                                               ` [llvm-dev] " Alexei Starovoitov
2015-08-12  5:28                                                 ` Wangnan (F)
2015-08-12 13:15                                                   ` Brenden Blanco
2015-08-13  6:24                                                     ` Wangnan (F)
2015-08-05  8:59                                         ` He Kuang [this message]
2015-08-06  3:41                                           ` [llvm-dev] [LLVMdev] Cc llvmdev: " Alexei Starovoitov
2015-08-06  4:31                                             ` Wangnan (F)
2015-08-06  6:50                                               ` Alexei Starovoitov
2015-07-13  8:29   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C1D055.2050205@huawei.com \
    --to=hekuang@huawei.com \
    --cc=ast@plumgrid.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm-dev@lists.llvm.org \
    --cc=pi3orama@163.com \
    --cc=wangnan0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).