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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
