Nagaraju Mekala via llvm-dev
2020-Apr-18 17:05 UTC
[llvm-dev] Debug symbols are missing in elf
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 >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/8c2e5b2a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_dump Type: application/octet-stream Size: 4232 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/8c2e5b2a/attachment.obj>
David Blaikie via llvm-dev
2020-Apr-18 17:41 UTC
[llvm-dev] Debug symbols are missing in elf
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? 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 >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/5beb1a39/attachment.html>
Nagaraju Mekala via llvm-dev
2020-Apr-20 04:25 UTC
[llvm-dev] Debug symbols are missing in elf
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