On Mon, Oct 11, 2010 at 10:43 AM, Chris Lattner <clattner at apple.com> wrote:> > On Oct 11, 2010, at 8:17 AM, Devang Patel wrote: > > >> Interestingly enough, I just upgraded to the latest Ubuntu (10.10 - > Maverick Meercat), and the LLVM-generated code no longer builds: I get the > following error in the assembler stage (after the bitcode is converted to > assembly): > >> > >> SwitchStmtTest.s: Assembler messages: > >> SwitchStmtTest.s:294899: Fatal error: duplicate .debug_line sections > >> > > > > This is a known Linux binutils bug. There is a llvm pr in bugzilla > database, I don't remember the no. though. > > Direct .o file writing support for ELF is nearing functionality, it will > define away this sort of issue. >While that is great news, I'd like to also keep the ability to build via assembly language, as the ability to examine the assembly has been useful in solving many otherwise difficult bugs. (Especially given the difficulties I've had getting source-level debugging to work.) For now, however, do you know if there is a workaround for this issue?> -Chris-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/79d23606/attachment.html>
On Oct 11, 2010, at 11:04 AM, Talin wrote:> On Mon, Oct 11, 2010 at 10:43 AM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 11, 2010, at 8:17 AM, Devang Patel wrote: > > >> Interestingly enough, I just upgraded to the latest Ubuntu (10.10 - Maverick Meercat), and the LLVM-generated code no longer builds: I get the following error in the assembler stage (after the bitcode is converted to assembly): > >> > >> SwitchStmtTest.s: Assembler messages: > >> SwitchStmtTest.s:294899: Fatal error: duplicate .debug_line sections > >> > > > > This is a known Linux binutils bug. There is a llvm pr in bugzilla database, I don't remember the no. though. > > Direct .o file writing support for ELF is nearing functionality, it will define away this sort of issue. > > While that is great news, I'd like to also keep the ability to build via assembly language, as the ability to examine the assembly has been useful in solving many otherwise difficult bugs. (Especially given the difficulties I've had getting source-level debugging to work.) > > For now, however, do you know if there is a workaround for this issue?Searching "debug_line" in all llvm PR at llvm.org/bugs would immediately lead you to http://llvm.org/bugs/show_bug.cgi?id=8210 Follow the trails and you'll have all the info for this Fatal error. - Devang [BTW, for your original dwarf error, focusing on DIFactory uses will unlikely to lead you towards real underlying issue. Your approach is equivalent to focusing on IRBuilder to find the cause of mis-compilation. ] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/4934f3c8/attachment.html>
On Mon, Oct 11, 2010 at 11:12 AM, Devang Patel <dpatel at apple.com> wrote:> > On Oct 11, 2010, at 11:04 AM, Talin wrote: > > On Mon, Oct 11, 2010 at 10:43 AM, Chris Lattner <clattner at apple.com>wrote: > >> >> On Oct 11, 2010, at 8:17 AM, Devang Patel wrote: >> >> >> Interestingly enough, I just upgraded to the latest Ubuntu (10.10 - >> Maverick Meercat), and the LLVM-generated code no longer builds: I get the >> following error in the assembler stage (after the bitcode is converted to >> assembly): >> >> >> >> SwitchStmtTest.s: Assembler messages: >> >> SwitchStmtTest.s:294899: Fatal error: duplicate .debug_line sections >> >> >> > >> > This is a known Linux binutils bug. There is a llvm pr in bugzilla >> database, I don't remember the no. though. >> >> Direct .o file writing support for ELF is nearing functionality, it will >> define away this sort of issue. >> > > While that is great news, I'd like to also keep the ability to build via > assembly language, as the ability to examine the assembly has been useful in > solving many otherwise difficult bugs. (Especially given the difficulties > I've had getting source-level debugging to work.) > > For now, however, do you know if there is a workaround for this issue? > > > Searching "debug_line" in all llvm PR at llvm.org/bugs would immediately > lead you to > http://llvm.org/bugs/show_bug.cgi?id=8210 > Follow the trails and you'll have all the info for this Fatal error. > > - > Devang > > [BTW, for your original dwarf error, focusing on DIFactory uses will > unlikely to lead you towards real underlying issue. Your approach is > equivalent to focusing on IRBuilder to find the cause of mis-compilation. ] > > I'm not sure I understand what you are saying. I'm not claiming thatDIFactory is incorrect. I'm saying I don't know how to use it properly. At the moment, I'm testing my frontend on both Unbuntu (Maverick Meercat) and OS X (Leopard). They both fail, but in completely different ways. On OS X, a lot of the debug info seems to be missing entirely, even though I am running dsymutil. That is, when I link the LLVM-generated modules with my runtime library (which is compiled by gcc) I only get debug information for the modules that were compiled by gcc. However, I've inspected the .bc files carefully and it appears as though the debug metadata is in fact there. I'm guessing at this point that there is something wrong with my linker. (Because I don't want to ship LLVM binaries around with my compiler, I have written a linker program which combines parts of 'opt' and 'llc', the GCStrategy pass, and the Reflection generator pass. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101013/2826c902/attachment.html>