mirror of https://lore.kernel.org/lkml/
 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 " 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome