[llvm-dev] Debug symbols are missing in elf
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 20 00:55:57 PDT 2020
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200420/4041359d/attachment.html>
More information about the llvm-dev
mailing list