[llvm-dev] Debug symbols are missing in elf
Nagaraju Mekala via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 21 03:03:49 PDT 2020
Hi James,
Thanks for reply.
When I looked in to the generated debug dump from the object file I
found that DW_AT_name is always (indirect string, offset: 0x0): clang
version 8.0.1, instead of variable names.
Below is a sample output of the debug dump.
Compilation Unit @ offset 0x0:
Length: 0x6a (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x0): clang
version 8.0.1
<10> DW_AT_language : 12 (ANSI C99)
<12> DW_AT_name : (indirect string, offset: 0x0): clang
version 8.0.1
<16> DW_AT_stmt_list : 0x0
<1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang
version 8.0.1
<1e> DW_AT_low_pc : 0x0
<22> DW_AT_high_pc : 0x6c
<1><26>: Abbrev Number: 2 (DW_TAG_subprogram)
<27> DW_AT_low_pc : 0x0
<2b> DW_AT_high_pc : 0x6c
<2f> DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1 (r1))
<31> DW_AT_name : (indirect string, offset: 0x0): clang
version 8.0.1
<35> DW_AT_decl_file : 1
<36> DW_AT_decl_line : 51
<37> DW_AT_type : <0x66>
<3b> DW_AT_external : 1
-Nagaraju
On Mon, Apr 20, 2020 at 1:26 PM James Henderson
<jh7370.2008 at my.bristol.ac.uk> wrote:
>
> It looks to me like the DWARF is corrupt somehow. What happens if you try using llvm-objdump (as opposed to a GNU-based objdump) to dump the information? What warning(s) do you see? That'll hopefully give a little more context as to what is going wrong.
>
> On Mon, 20 Apr 2020 at 05:26, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> On Sat, Apr 18, 2020 at 11:11 PM David Blaikie <dblaikie at gmail.com> wrote:
>> >
>> > Yeah, not sure - you mention the linker produces errors, but the errors you showed looked like objdump errors? Were those errors from trying to dump the linked executable, and not errors that were produced by the linker itself?
>> Yes, as mentioned earlier I was able to generate final executable but
>> it doesn't have debug symbols. When I tried to run objdump on the
>> final executable, it was showing those warning messages and continued
>> to generate disassembly without .debug sections init.
>>
>> > But yeah, don't really know what's happening there. Might be you need to debug the linker & see what it's reading/being confused by.
>> >
>> > On Sat, Apr 18, 2020 at 10:05 AM Nagaraju Mekala <nagaraju.mekala87 at gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Saturday, April 18, 2020, David Blaikie <dblaikie at gmail.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Apr 18, 2020 at 3:02 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> >>>>
>> >>>> Hello All,
>> >>>>
>> >>>> I was trying to add Microblaze target to LLVM backend. I was able to
>> >>>> generate object file with relocations. and debug symbols.
>> >>>>
>> >>>> When I try to link this object file with microblaze GCC linker I am
>> >>>> getting below errors and debug symbols are missing in it.
>> >>>>
>> >>>> mb-objdump: DWARF error: found dwarf version '15877', this reader only
>> >>>> handles version 2, 3, 4 and 5 information
>> >>>> mb--objdump: DWARF error: found dwarf version '3328', this reader only
>> >>>> handles version 2, 3, 4 and 5 information
>> >>>> mb--objdump: DWARF error: found dwarf version '1280', this reader only
>> >>>> handles version 2, 3, 4 and 5 information
>> >>>>
>> >>>> Any idea when does the above errors will come?
>> >>>> The llvm generated object file has debug symbols,
>> >>>
>> >>>
>> >>> When you say "has debug symbols" what do you mean? What tools have you used to observe these symbols/information?
>> >>
>> >>
>> >> I have observed the debug sections with mb-objdump with -xSD flag (binutils based objdump which we use it with mb-gcc compiler). Even with readelf I was able to get the dwarf sections.
>> >> Attached is the dwarf dump generated with readelf --debug-dump helloworld.o command..
>> >>
>> >>>> where as elf doesn't have.
>> >>>
>> >>>
>> >>> I take it you mean the linked executable? (the "ELF" file format is used for both the object files and the linked executable)
>> >>>
>> >>>
>> >>
>> >> Sorry for the confusion. You are correct, I meant the linked executable.
>> >>
>> >>>> I tried modifying MCTarget layer a lot but not able to find the root-cause.
>> >>>> Any clue is much appreciated.
>> >>>>
>> >>>> ex:
>> >>>> hello.c
>> >>>> int main()
>> >>>> {
>> >>>> printf("Hello World\n\r");
>> >>>> printf("Successfully ran Hello World application");
>> >>>> return 0;
>> >>>> }
>> >>>>
>> >>>> hello.o objdump:
>> >>>> int main()
>> >>>> {
>> >>>> 0: 10a00000 addk r5, r0, r0
>> >>>> 4: f8a1002c swi r5, r1, 44
>> >>>>
>> >>>> printf("Hello World\n\r");
>> >>>> 8: b0000000 imm 0
>> >>>> 8: R_MICROBLAZE_64 .rodata.str1.1
>> >>>> c: a0c00000 ori r6, r0, 0
>> >>>> 10: f8a10028 swi r5, r1, 40
>> >>>> 14: b0000000 imm 0
>> >>>> 14: R_MICROBLAZE_64_PCREL printf
>> >>>> 18: b9f40000 brlid r15, 0
>> >>>> 1c: 10a60000 addk r5, r6, r0
>> >>>> printf("Successfully ran Hello World application");
>> >>>> 20: b0000000 imm 0
>> >>>> 20: R_MICROBLAZE_64 .rodata.str1.1+0xe
>> >>>> 24: a0a00000 ori r5, r0, 0
>> >>>> 28: b0000000 imm 0
>> >>>> 28: R_MICROBLAZE_64_PCREL printf
>> >>>> 2c: b9f40000 brlid r15, 0
>> >>>> 30: f8610024 swi r3, r1, 36
>> >>>> return 0;
>> >>>> 34: e8a10028 lwi r5, r1, 40
>> >>>> 38: f8610020 swi r3, r1, 32
>> >>>> 3c: 10650000 addk r3, r5, r0
>> >>>> 40: b60f0008 rtsd r15, 8
>> >>>> 44: 80000000 or r0, r0, r0
>> >>>> ....
>> >>>> ...
>> >>>>
>> >>>> hello.elf objdump
>> >>>> 8000021c <main>:
>> >>>> 8000021c: 10a00000 addk r5, r0, r0
>> >>>> 80000220: f8a1002c swi r5, r1, 44
>> >>>> 80000224: b0008000 imm -32768
>> >>>> 80000228: a0c0f418 ori r6, r0, -3048
>> >>>> 8000022c: f8a10028 swi r5, r1, 40
>> >>>> 80000230: b9f400ec brlid r15, 236
>> >>>> 80000234: 10a60000 addk r5, r6, r0
>> >>>> 80000238: b0008000 imm -32768
>> >>>> 8000023c: a0a0f426 ori r5, r0, -3034
>> >>>> 80000240: b9f400dc brlid r15, 220
>> >>>> 80000244: f8610024 swi r3, r1, 36
>> >>>> 80000248: e8a10028 lwi r5, r1, 40
>> >>>> 8000024c: f8610020 swi r3, r1, 32
>> >>>> 80000250: 10650000 addk r3, r5, r0
>> >>>> 80000254: b60f0008 rtsd r15, 8
>> >>>> 80000258: 80000000 or r0, r0, r0
>> >>>>
>> >>>> Thanks in Advance,
>> >>>> Nagaraju
>> >>>> _______________________________________________
>> >>>> LLVM Developers mailing list
>> >>>> llvm-dev at lists.llvm.org
>> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
More information about the llvm-dev
mailing list