similar to: [LLVMdev] DIBuilder interface change

On Oct 27, 2011, at 10:39 PM, Talin wrote: > On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 23, 2011, at 12:03 AM, Talin wrote: > >> Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.) >> >>

On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 23, 2011, at 12:03 AM, Talin wrote: > > Just a follow up on this - I am still having problems, I never did figure > out a solution. (I've been running with debug off for the last month so that > I could get work done.) > > Here's what I am seeing: I am definitely calling

Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.) Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting

On Oct 23, 2011, at 12:03 AM, Talin wrote: > Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.) > > Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the

Yup. Now, the debug info nodes do not refer to compile unit. - Devang On Sep 5, 2011, at 2:23 AM, Duncan Sands wrote: > Hi Talin, I mentioned it because the error message you are getting is > identical (IIRC) to the error message being produced by llvm-gcc before > this patch went in. > > Ciao, Duncan. > > On 05/09/11 11:21, Talin wrote: >> On Sun, Sep 4, 2011 at

Hi Talin, > So, I just sync'd to LLVM tip and added the call to DIBuilder::finalize(). But > even with that change I am getting an error when I try to run llc: > > Assertion failed: (TheCU && "Unable to find compile unit!"), function > endFunction, file > /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306. > > And looking at

So, I just sync'd to LLVM tip and added the call to DIBuilder::finalize(). But even with that change I am getting an error when I try to run llc: Assertion failed: (TheCU && "Unable to find compile unit!"), function endFunction, file /Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306. And looking at the .bc dissassembly, I see there are indeed

Hi Talin, I mentioned it because the error message you are getting is identical (IIRC) to the error message being produced by llvm-gcc before this patch went in. Ciao, Duncan. On 05/09/11 11:21, Talin wrote: > On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Talin, > > > So, I just

Hi Talin, Followup as promised: in our case we weren't calling finalize(). As this manifests itself as exactly the same assertion failure as yours I suggest you double-check you are actually calling it before any passes run on the Module. Functionally, instead of maintaining a pointer to the CU in all Debug nodes, the main CompilationUnit node has a list of subprogram nodes. It is from this

On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Talin, > > > So, I just sync'd to LLVM tip and added the call to > DIBuilder::finalize(). But > > even with that change I am getting an error when I try to run llc: > > > > Assertion failed: (TheCU && "Unable to find compile unit!"), function > >

On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: > Hi All, > DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs > to encode debugging information. We are replacing this interface with new > simple interface, DIBuilder. > Here is one example that demonstrates differences between two interfaces. To > create debug information

Hi, Thanks for bringing this up, I'm just about to investigate an identical case which has broken our front-end. Both ours and clang generate subroutineinfo with null compilationunits, but ours asserts and clang's doesn't. I'll take a look at this on Monday, if it is a bug in LLVM. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu

On Sep 23, 2011, at 12:39 PM, Talin wrote: > Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a

On Aug 22, 2011, at 6:48 AM, Irina Lipov wrote: > Hi, > I saw your update regarding "The DIBuilder interface used by front ends to encode debugging information in the LLVM IR now expects clients to use DIBuilder::finalize() at the end of translation unit to complete debugging information encoding" > Does it mean that in the new version you defer emission of some debug info

Hi All, DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs to encode debugging information. We are replacing this interface with new simple interface, DIBuilder. Here is one example that demonstrates differences between two interfaces. To create debug information entries to encode volatile type one would use following call in a language front end,

On Feb 25, 2011, at 5:23 AM, Renato Golin wrote: > On 24 February 2011 21:34, Jason Kim <jasonwkim at google.com> wrote: >> On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: > > It simplified a bit type construction but the overall code did not > reduce that much. The old interface expected FEs to keep track of everything, where as new

On 24 February 2011 21:34, Jason Kim <jasonwkim at google.com> wrote: > On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: It simplified a bit type construction but the overall code did not reduce that much. It's still very similar to the previous style but had a few differences in the IR output. We had LIT tests that checked the IR and Dwarf and GDB

On 25 February 2011 16:55, Devang Patel <dpatel at apple.com> wrote: > The old interface expected FEs to keep track of everything, where as new interface tries to encapsulate as much info as possible. This should help cleanup FE code responsible to generate debugging information. I made a first pass in clang and simplified code little bit. There is more room for improvement now. If you

Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine. I took a look at the code in DIBuilder.cpp,

On 21 February 2011 18:17, Devang Patel <dpatel at apple.com> wrote: > TheCU is an internal debug info information that FE should not care about. DIBuilder is meant to use for one translation unit by FE. If all the internal debug info information is exposed to FE then you'll get DIFactory. I agree, DIBuilder should not expose its internal structure. This is why, on a C-only world,