| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <55B35F42.70803@huawei.com>
Date: Sat, 25 Jul 2015 18:04:50 +0800
From: He Kuang <hekuang@...wei.com>
To: Alexei Starovoitov <ast@...mgrid.com>,
"Wangnan (F)" <wangnan0@...wei.com>, pi3orama <pi3orama@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce
function for outputing data to perf event
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists