On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote:> > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that I've emitted into > > my module > > is correct or even sensible. The only way to test it is to try and > > debug it > > with gdb, but all that will tell you is that *something* failed - it > > won't > > tell you where or what. It's not so much like looking for a needle > > in a > > haystack - more like looking for a particular needle in a needlestack. > > You can also try running "dwarfdump --verify" on your dsymutil file > (not on the dSYM bundle, but on the file inside the bundle). It > sometimes gives a bit more information. Also simply using "dwarfdump - > a" can be helpful to see wrong references (e.g., if the type info is > structurally invalid then dwarfdump may simply stop dumping at that > point, so you know where the error is). > > Ah OK thanks, that's helpful.I tried what you suggested, and it prints out about 4000 lines and then segfaults, The last lines that it prints out are: .debug_frame contents: 0x00000000: CIE length: 0x00000010 CIE_id: 0xffffffff version: 0x01 augmentation: "" code_align: 1 data_align: -4 ra_register: 0x08 DW_CFA_def_cfa (4 (esp), 4) DW_CFA_offset (8 (eip), 0) DW_CFA_nop DW_CFA_nop Instructions: Init State: CFA=esp+4 eip=[CFA] 0x00000014: FDE length: 0x00000028 CIE_pointer: 0x00000000 I'm not sure how the contents of this structure relate to the various LLVM API calls used in creating debugging info...> > Jonas > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/2ab543ea/attachment.html>
On Wed, Sep 1, 2010 at 8:31 AM, Talin <viridia at gmail.com> wrote:> On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > >> >> On 01 Sep 2010, at 08:47, Talin wrote: >> >> > Once again, I have no idea what this means or how to go about >> > debugging it. >> > This is my biggest frustration with DIFactory - there's absolutely >> > no way to >> > verify that the DWARF debugging information that I've emitted into >> > my module >> > is correct or even sensible. The only way to test it is to try and >> > debug it >> > with gdb, but all that will tell you is that *something* failed - it >> > won't >> > tell you where or what. It's not so much like looking for a needle >> > in a >> > haystack - more like looking for a particular needle in a needlestack. >> >> You can also try running "dwarfdump --verify" on your dsymutil file >> (not on the dSYM bundle, but on the file inside the bundle). It >> sometimes gives a bit more information. Also simply using "dwarfdump - >> a" can be helpful to see wrong references (e.g., if the type info is >> structurally invalid then dwarfdump may simply stop dumping at that >> point, so you know where the error is). >> >> Ah OK thanks, that's helpful. > > I tried what you suggested, and it prints out about 4000 lines and then > segfaults, The last lines that it prints out are: > > .debug_frame contents: > > 0x00000000: CIE > length: 0x00000010 > CIE_id: 0xffffffff > version: 0x01 > augmentation: "" > code_align: 1 > data_align: -4 > ra_register: 0x08 > DW_CFA_def_cfa (4 (esp), 4) > DW_CFA_offset (8 (eip), 0) > DW_CFA_nop > DW_CFA_nop > Instructions: Init State: CFA=esp+4 eip=[CFA] > > > 0x00000014: FDE > length: 0x00000028 > CIE_pointer: 0x00000000 > > > I'm not sure how the contents of this structure relate to the various LLVM > API calls used in creating debugging info... >OK I figured it out, something is wrong with my descriptors for local variables... Thanks again! :)> >> Jonas >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > -- > -- Talin >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/ce899b97/attachment.html>
Hello,
May I ask what the issue was and how you solved it?
I get the same error just by emitting the compile unit di.
My code to create the compile unit di:
di.createCompileUnit(DW_LANG_Poke,
file == NULL ? "_nofile_" : file->getName(),
file == NULL ? "" : file->getParent().getPath(),
POKE_NAME_AND_VERSION,
false, "", 0);
This is the only debug info generation I do. Without it gdb will accept the
resulting executable without complaints, but with it I get the
"DW_FORM_strp
pointing outside of .debug_str section" error same as you did.
The executable is compiled from the following files by first running my
compiler, then llc on the output and finally clang on the assembler code:
llc -filetype=asm test2.pk.ll && clang *.s
Source code in my language: http://emil.djupfeldt.se/poke/test2.pk
Generated llvm code: http://emil.djupfeldt.se/poke/test2.pk.ll
Generated x86 assembler code: http://emil.djupfeldt.se/poke/test2.pk.s
regards,
Emil Djupfeldt