BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack crawler, for one), I'm hoping that time and a fresh start will yield better results. Unfortunately after about a day spent reviewing old llvm-dev threads and trying different permutations of calls to DIFactory, I have not discovered anything that I didn't already know. With respect to the suggestion of building my own copy of dwarfdump (so that I could run it under gdb and see where it breaks), I never did get it to compile and run on OS X, since it requires ELF headers and libs. I thought about doing the same thing under Linux, however dwarfdump doesn't segfault on Linux when I feed it my LLVM-generated binary. (It does report errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is that it does this even when I completely disable the code that calls IRBuilder.SetCurrentDebugLocation()). As per usual, this is with a recent LLVM head (like about a week old). On Tue, Sep 7, 2010 at 9:21 AM, Devang Patel <dpatel at apple.com> wrote:> > On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > > On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: > > Your recent changes mentioned below would change correctness of debug info, > > but it would unlikely to impact structure of DWARF generated. And somehow, > > this structure is invalid in your case. > > > I was hoping for a quick-fix on the assumptions of DwarfDebug about > Subprograms' MDNodes, but it might be anywhere. > > Reducing the test case is the best solution, but it might not be easy. > > Validating the MDNodes in DIFactory (or anywhere before DwarfDebug) > would be a good step to ensure IR consistency and isolate problems. > Unfortunately, it is the kind of thing that is not fundamental to get > things working, so it always gets left behind... ;) > > > I understand your point and certainly acknowledge need for better > documentation. > > There are couple of wrinkles to note here > - While constructing IR using DIFactory you are not seeing entire picture. > When you see a declaration you're not sure whether you'll see matching def. > or not. When you build a inlined subprogram, you don't know whether you'll > see a out of line definition of this function or not. etc... > - DwarfDebug must be able to handle malformed debug info gracefully and > make best out of whatever is fed. This is because, optimizer may have chewed > on IR mercilessly and optimizer must not be influenced by presence of > encoded debug info in IR. > > - > Devang >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101010/6f4b961e/attachment.html>
On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote:> BTW, the reason I stopped responding to this thread is not because I solved > the problem, but because I simply gave up and decided to work on other > things for a while since I was making no progress. Having finished those > other things (the stack crawler, for one), I'm hoping that time and a fresh > start will yield better results. Unfortunately after about a day spent > reviewing old llvm-dev threads and trying different permutations of calls to > DIFactory, I have not discovered anything that I didn't already know. > > With respect to the suggestion of building my own copy of dwarfdump (so > that I could run it under gdb and see where it breaks), I never did get it > to compile and run on OS X, since it requires ELF headers and libs. I > thought about doing the same thing under Linux, however dwarfdump doesn't > segfault on Linux when I feed it my LLVM-generated binary. (It does report > errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is > that it does this even when I completely disable the code that calls > IRBuilder.SetCurrentDebugLocation()). >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 Note that this is still with calls to IRBuilder.SetCurrentDebugLocation() disabled - My FE is not emitting any debug line information at all at this time.> As per usual, this is with a recent LLVM head (like about a week old). > > On Tue, Sep 7, 2010 at 9:21 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: >> >> On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: >> >> Your recent changes mentioned below would change correctness of debug >> info, >> >> but it would unlikely to impact structure of DWARF generated. And somehow, >> >> this structure is invalid in your case. >> >> >> I was hoping for a quick-fix on the assumptions of DwarfDebug about >> Subprograms' MDNodes, but it might be anywhere. >> >> Reducing the test case is the best solution, but it might not be easy. >> >> Validating the MDNodes in DIFactory (or anywhere before DwarfDebug) >> would be a good step to ensure IR consistency and isolate problems. >> Unfortunately, it is the kind of thing that is not fundamental to get >> things working, so it always gets left behind... ;) >> >> >> I understand your point and certainly acknowledge need for better >> documentation. >> >> There are couple of wrinkles to note here >> - While constructing IR using DIFactory you are not seeing entire picture. >> When you see a declaration you're not sure whether you'll see matching def. >> or not. When you build a inlined subprogram, you don't know whether you'll >> see a out of line definition of this function or not. etc... >> - DwarfDebug must be able to handle malformed debug info gracefully and >> make best out of whatever is fed. This is because, optimizer may have chewed >> on IR mercilessly and optimizer must not be influenced by presence of >> encoded debug info in IR. >> >> - >> Devang >> > > > > -- > -- Talin >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101010/83db9c7e/attachment.html>
On Oct 10, 2010, at 7:21 PM, Talin <viridia at gmail.com> wrote:> On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote: > BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack crawler, for one), I'm hoping that time and a fresh start will yield better results. Unfortunately after about a day spent reviewing old llvm-dev threads and trying different permutations of calls to DIFactory, I have not discovered anything that I didn't already know. > > With respect to the suggestion of building my own copy of dwarfdump (so that I could run it under gdb and see where it breaks), I never did get it to compile and run on OS X, since it requires ELF headers and libs. I thought about doing the same thing under Linux, however dwarfdump doesn't segfault on Linux when I feed it my LLVM-generated binary. (It does report errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is that it does this even when I completely disable the code that calls IRBuilder.SetCurrentDebugLocation()). > > 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. - Devang> Note that this is still with calls to IRBuilder.SetCurrentDebugLocation() disabled - My FE is not emitting any debug line information at all at this time. > > > As per usual, this is with a recent LLVM head (like about a week old). > > On Tue, Sep 7, 2010 at 9:21 AM, Devang Patel <dpatel at apple.com> wrote: > > On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > >> On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: >>> Your recent changes mentioned below would change correctness of debug info, >>> but it would unlikely to impact structure of DWARF generated. And somehow, >>> this structure is invalid in your case. >> >> I was hoping for a quick-fix on the assumptions of DwarfDebug about >> Subprograms' MDNodes, but it might be anywhere. >> >> Reducing the test case is the best solution, but it might not be easy. >> >> Validating the MDNodes in DIFactory (or anywhere before DwarfDebug) >> would be a good step to ensure IR consistency and isolate problems. >> Unfortunately, it is the kind of thing that is not fundamental to get >> things working, so it always gets left behind... ;) >> > > I understand your point and certainly acknowledge need for better documentation. > > There are couple of wrinkles to note here > - While constructing IR using DIFactory you are not seeing entire picture. When you see a declaration you're not sure whether you'll see matching def. or not. When you build a inlined subprogram, you don't know whether you'll see a out of line definition of this function or not. etc... > - DwarfDebug must be able to handle malformed debug info gracefully and make best out of whatever is fed. This is because, optimizer may have chewed on IR mercilessly and optimizer must not be influenced by presence of encoded debug info in IR. > > - > Devang > > > > -- > -- Talin > > > > -- > -- Talin-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/4f3b3309/attachment.html>