Nagaraju Mekala via llvm-dev
2020-Apr-21 10:03 UTC
[llvm-dev] Debug symbols are missing in elf
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
Robinson, Paul via llvm-dev
2020-Apr-21 12:46 UTC
[llvm-dev] Debug symbols are missing in elf
> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > Mekala via llvm-dev > Sent: Tuesday, April 21, 2020 6:04 AM > To: jh7370.2008 at my.bristol.ac.uk > Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Debug symbols are missing in elf > > 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.That symptom suggests that relocations from .debug_info to .debug_str are not being handled correctly. Either your backend is not emitting them correctly, or the dumper does not know what to do with them. If you are able to dump the .rela.debug_info section and it looks reasonable, the fault is most likely with the dumper. If you are using llvm-dwarfdump then that should not be hard to solve. --paulr> > 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
Nagaraju Mekala via llvm-dev
2020-Apr-22 16:27 UTC
[llvm-dev] Debug symbols are missing in elf
On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote:> > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > > Mekala via llvm-dev > > Sent: Tuesday, April 21, 2020 6:04 AM > > To: jh7370.2008 at my.bristol.ac.uk > > Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> > > Subject: Re: [llvm-dev] Debug symbols are missing in elf > > > > 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. > > That symptom suggests that relocations from .debug_info to .debug_str > are not being handled correctly. Either your backend is not emitting > them correctly, or the dumper does not know what to do with them. > > If you are able to dump the .rela.debug_info section and it looks > reasonable, the fault is most likely with the dumper. If you are > using llvm-dwarfdump then that should not be hard to solve. > --paulr >Hi Paulr, Thanks for the reply.>From your suggestion I have used llvm-dwarfdump and was able to figureout that debug_info section was incomplete. Can you please help me in finding which part of the target(Backend files) will construct the dwarf data, especially debug_info. Thanks in Advance, Nagaraju> > > > 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 >
Possibly Parallel Threads
- Debug symbols are missing in elf
- Debug symbols are missing in elf
- Debug symbols are missing in elf
- [LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
- [LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?