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>
Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Date: Fri, 24 Jul 2015 12:16:03 +0800 [thread overview]
Message-ID: <55B1BC03.9020708@huawei.com> (raw)
In-Reply-To: <55B1AEE9.1080207@plumgrid.com>
Hi, Alexei
On 2015/7/24 11:20, Alexei Starovoitov wrote:
> On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
>> On 7/23/15 4:54 AM, He Kuang wrote:
>>
>> trimmed cc-list, since it's not related to kernel.
>>
>>> Thank you for your guidence, and by referencing your last mail
>>> and other llvm backends, I found setting
>>> BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h
>>
>> thanks! yes. it was missing.
>>
>>> and fix some unhandeled switch can make llc output debug_info,
>>
>> what do you mean ?
>>
>>> but important information is missing in the result:
>>
>> hmm. I see slightly different picture.
>> With 'clang -O2 -target bpf -g -S a.c'
>> I see all the right info inside .s file.
>> with '-c a.c' for some reasons it produces bogus offset:
>> Abbrev Offset: 0xffff0000
>> Pointer Size: 8
>> /usr/local/bin/objdump: Warning: Debug info is corrupted, abbrev offset
>> (ffff0000) is larger than abbrev section size (4b)
>>
>> and objdump fails to parse .o
>> I'm using llvm trunk 3.8. Do you see this as well?
>
> there were few issues related to relocations.
> Fixed it up and pushed to llvm trunk r243087.
> Please pull and give it a try.
> AT_location should be correct, but AT_name still looks buggy.
I've pulled the lastest version "[bpf] initial support for
debug_info" and tested it. This version can output debug_info but
still not generate correct AT_location, I tested as following:
$ cat > main.c <<EOF
int testprog(int myvar_a, int myvar_b)
{
int myvar_c;
myvar_c = myvar_a + myvar_b;
return myvar_c;
}
EOF
$ clang -g -O2 -target bpf -c main.c -o test.obj.bpf
$ clang -g -O2 -c main.c -o test.obj.x86
$ objdump --dwarf=info test.obj.x86 > test.obj.x86.dump
$ objdump --dwarf=info test.obj.bpf > test.obj.bpf.dump
Compare those two dump files:
test.obj.x86.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_location : 3 byte block: 55 93 4 (DW_OP_reg5 (rdi);
DW_OP_piece: 4)
<48> DW_AT_name : (indirect string, offset: 0xdc): myvar_a
<4c> DW_AT_decl_file : 1
<4d> DW_AT_decl_line : 1
<4e> DW_AT_type : <0x71>
test.obj.bpf.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_name : (indirect string, offset: 0x0): clang
version 3.8.0 (http://llvm.org/git/clang.git
3a7c733b80f156a547f3f1517e6fbce9c0a33026)
(http://llvm.org/git/llvm.git
90908cb34d73460d3 a83e2194a58d82c6d1f199)
<48> DW_AT_decl_file : 1
<49> DW_AT_decl_line : 1
<4a> DW_AT_type : <0x65>
No DW_AT_location info for formal parameters, but if we change
the function 'testprog' to 'main', DW_AT_location of formal
parameters appear but that of local variables are still missed,
don't know why..
$ cat > main.c <<EOF
#include <stdio.h>
int main(int argc, char *argv[])
{
int myvar_a, myvar_b;
int myvar_c;
myvar_c = myvar_a + myvar_b;
return myvar_c;
}
test.obj.bpf.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (r1))
<46> DW_AT_name : (indirect string, offset: 0x0): clang version 3.8.
..
<2><5d>: Abbrev Number: 4 (DW_TAG_variable)
<5e> DW_AT_name : (indirect string, offset: 0x0): clang version 3.8.
test.obj.x86.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_location : 3 byte block: 55 93 4 (DW_OP_reg5 (rdi);
DW_OP_piece: 4)
<48> DW_AT_name : (indirect string, offset: 0xd8): argc
..
<2><5f>: Abbrev Number: 4 (DW_TAG_variable)
<60> DW_AT_name : (indirect string, offset: 0xe7): myvar_a
..
Thank you.
next prev parent reply other threads:[~2015-07-24 4:16 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 [this message]
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 ` [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=55B1BC03.9020708@huawei.com \
--to=hekuang@huawei.com \
--cc=ast@plumgrid.com \
--cc=linux-kernel@vger.kernel.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).