[llvm-dev] Debug symbols are missing in elf

[Nagaraju Mekala via llvm-dev]

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, where as elf doesn't have.
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...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[David Blaikie via llvm-dev]

On Sat, Apr 18, 2020 at 3:02 AM Nagaraju Mekala via llvm-dev <llvm...@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?

 

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)
 

[Nagaraju Mekala via llvm-dev]

On Saturday, April 18, 2020, David Blaikie <dbla...@gmail.com> wrote:

On Sat, Apr 18, 2020 at 3:02 AM Nagaraju Mekala via llvm-dev <llvm...@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. 

[David Blaikie via llvm-dev]

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.

[Nagaraju Mekala via llvm-dev]

On Sat, Apr 18, 2020 at 11:11 PM David Blaikie <dbla...@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.

[James Henderson via llvm-dev]

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.

[Nagaraju Mekala via llvm-dev]

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

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Nagaraju
> Mekala via llvm-dev
> Sent: Tuesday, April 21, 2020 6:04 AM
> To: jh737...@my.bristol.ac.uk
> Cc: LLVM Developers Mailing List <llvm...@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

[Nagaraju Mekala via llvm-dev]

On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.r...@sony.com> wrote:
>
>
>
> > -----Original Message-----
> > From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Nagaraju
> > Mekala via llvm-dev
> > Sent: Tuesday, April 21, 2020 6:04 AM
> > To: jh737...@my.bristol.ac.uk
> > Cc: LLVM Developers Mailing List <llvm...@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 figure
out 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

[David Blaikie via llvm-dev]

What command did you run, on what file, and what was the output?

 

Can you please help me in finding which part of the target(Backend
files) will construct the dwarf data, especially debug_info.

LLVM's DWARF generation is implemented in llvm/lib/CodeGen/AsmPrinter/Dwarf* files
 

[Nagaraju Mekala via llvm-dev]

Hi David,

Thanks for the reply.

> What command did you run, on what file, and what was the output?

I ran llvm-dwarf with -verbose option. It gave me the verbose print as below
0x0000000b: DW_TAG_compile_unit [1] *
DW_AT_producer [DW_FORM_strp] (
.debug_str[0x00000000] = "clang version 8.0.1 ")
DW_AT_language [DW_FORM_data2] (DW_LANG_C99)
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] =
"clang version 8.0.1 ")
DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000)
DW_AT_comp_dir [DW_FORM_strp] (
.debug_str[0x00000000] = "clang version 8.0.1 ")
Similarly as above snippet .debug_str is always pointing to 0x00000
for everything.

>>
>> Can you please help me in finding which part of the target(Backend
>> files) will construct the dwarf data, especially debug_info.
>
>
> LLVM's DWARF generation is implemented in llvm/lib/CodeGen/AsmPrinter/Dwarf* files

Are there any backend specific functions or files which will effect
dwarf generation of that particular target?
I can find only "SupportsDebugInformation = true;" in MCAsmInfo.

-Nagaraju

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: Nagaraju Mekala <nagaraju...@gmail.com>
> Sent: Thursday, April 23, 2020 7:08 AM
> To: David Blaikie <dbla...@gmail.com>
> Cc: Robinson, Paul <paul.r...@sony.com>; llvm...@lists.llvm.org
> Subject: Re: [llvm-dev] Debug symbols are missing in elf
>

I am still suspecting that the relocations aren't handled correctly.
Does llvm/lib/Object/RelocationResolver.cpp support your target?
--paulr

> >> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-
> dev__;!!JmoZiZGBv3RvKRSx!qi4GZS3A247leq6emwOos2zrzpOu4VcG52tDez40r-
> UDF_pjjcVB68-L5MIBp8suIg$

[Nagaraju Mekala via llvm-dev]

Hi Paulr,
You are correct, the issue was due to not handling the relocations properly.
After returning the proper relocation in getRelocType function, the
error went away.
Now the debug symbols are coming up on the final GCC linked executable.

Thanks,
Nagaraju