From: "Wangnan (F)" <wangnan0@huawei.com>
To: Alexei Starovoitov <ast@plumgrid.com>,
He Kuang <hekuang@huawei.com>, pi3orama <pi3orama@163.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Date: Fri, 31 Jul 2015 18:18:50 +0800 [thread overview]
Message-ID: <55BB4B8A.5000207@huawei.com> (raw)
In-Reply-To: <55B909B2.2080606@plumgrid.com>
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
next prev parent reply other threads:[~2015-07-31 10:19 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) [this message]
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 ` [LLVMdev] Cc llvmdev: " He Kuang
2015-08-06 3:41 ` [llvm-dev] " 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=55BB4B8A.5000207@huawei.com \
--to=wangnan0@huawei.com \
--cc=ast@plumgrid.com \
--cc=hekuang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pi3orama@163.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).