All of lore.kernel.org
 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>
Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Date: Sat, 25 Jul 2015 18:04:50 +0800	[thread overview]
Message-ID: <55B35F42.70803@huawei.com> (raw)
In-Reply-To: <55B1BC03.9020708@huawei.com>

Hi, Alexei

On 2015/7/24 12:16, He Kuang wrote:
> 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.
>
>

Share some infomation on debuging bpf debuginfo problem.

An error "error: failed to compute relocation: Unknown" can be
found if we use llvm-dwarfdump tools to dump the object file,
debuging on that error, it seems there's no support for type
'BPF' in llvm/include/llvm/Support/MachO.h, and llvm-dwarfdump
fails to find the corresponding VisitElf method. Then I have a
rough test which forces RelocVisitor to use 'visitELF_386_32',
and got the correct DW_AT_name in the output:

0x00000043: DW_TAG_formal_parameter [3]
             DW_AT_name [DW_FORM_strp]	( .debug_str[0x000000dc] = "myvar_a")
             DW_AT_decl_file [DW_FORM_data1]	("testllvm/main.c")
             DW_AT_decl_line [DW_FORM_data1]	(3)
             DW_AT_type [DW_FORM_ref4]	(cu + 0x0065 => {0x00000065})

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.

Thank you.




  reply	other threads:[~2015-07-25 10:05 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 [this message]
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=55B35F42.70803@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.