Nagaraju Mekala via llvm-dev
2020-Apr-23 11:08 UTC
[llvm-dev] Debug symbols are missing in elf
On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote:> > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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 figure >> out that debug_info section was incomplete. > >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* filesAre 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>> >> >> 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 >> > >> _______________________________________________ >> 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-23 15:02 UTC
[llvm-dev] Debug symbols are missing in elf
> -----Original Message----- > From: Nagaraju Mekala <nagaraju.mekala87 at gmail.com> > Sent: Thursday, April 23, 2020 7:08 AM > To: David Blaikie <dblaikie at gmail.com> > Cc: Robinson, Paul <paul.robinson at sony.com>; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Debug symbols are missing in elf > > On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm- > dev at lists.llvm.org> wrote: > >> > >> 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 figure > >> out that debug_info section was incomplete. > > > > > 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.I am still suspecting that the relocations aren't handled correctly. Does llvm/lib/Object/RelocationResolver.cpp support your target? --paulr> >> > >> 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 > >> > >> > >> 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 > >> > > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://urldefense.com/v3/__https://lists.llvm.org/cgi- > bin/mailman/listinfo/llvm- > dev__;!!JmoZiZGBv3RvKRSx!qi4GZS3A247leq6emwOos2zrzpOu4VcG52tDez40r- > UDF_pjjcVB68-L5MIBp8suIg$
Nagaraju Mekala via llvm-dev
2020-Apr-28 09:20 UTC
[llvm-dev] Debug symbols are missing in elf
On Thu, Apr 23, 2020 at 8:32 PM Robinson, Paul <paul.robinson at sony.com> wrote:> > > > > -----Original Message----- > > From: Nagaraju Mekala <nagaraju.mekala87 at gmail.com> > > Sent: Thursday, April 23, 2020 7:08 AM > > To: David Blaikie <dblaikie at gmail.com> > > Cc: Robinson, Paul <paul.robinson at sony.com>; llvm-dev at lists.llvm.org > > Subject: Re: [llvm-dev] Debug symbols are missing in elf > > > > On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm- > > dev at lists.llvm.org> wrote: > > >> > > >> 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 figure > > >> out that debug_info section was incomplete. > > > > > > > > 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. > > I am still suspecting that the relocations aren't handled correctly. > Does llvm/lib/Object/RelocationResolver.cpp support your target? > --paulr >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> > >> > > >> 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 > > >> > > >> > > >> 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 > > >> > > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> llvm-dev at lists.llvm.org > > >> https://urldefense.com/v3/__https://lists.llvm.org/cgi- > > bin/mailman/listinfo/llvm- > > dev__;!!JmoZiZGBv3RvKRSx!qi4GZS3A247leq6emwOos2zrzpOu4VcG52tDez40r- > > UDF_pjjcVB68-L5MIBp8suIg$