search for: dassert

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

...u have to use the Subprogram type only for the return type"). Here's what my code for creating function descriptors currently looks like (note that some parts are commented out for debugging purposes): DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, Function * f) { DASSERT(fn != NULL); // Look up in the map to see if already generated. DISubprogram & sp = dbgSubprograms_[fn]; if (!sp.isSubprogram()) { DIType dbgFuncType = genDIType(fn->functionType()); DASSERT(dbgFuncType.Verify()); DASSERT(dbgCompileUnit_.Verify()); sp = dbgFactory_.Crea...

...!= NULL ? param->name() : "", > genDIFile(param), > getSourceLineNumber(param->location()), > getSizeOfInBits(param->internalType()->irParameterType()), > getInt64Val(0), > getInt64Val(0), 0, > ptype); > DASSERT(ptype.Verify()); > args.push_back(ptype); > } > > > However, if I go by what's in clang, it seems that the > DW_TAG_formal_parameter is unnecessary. Is this correct? > > And I'd still like to see some of these questions addressed in the actual > HTML documen...

On Aug 31, 2010, at 9:03 AM, Talin wrote: > 4) What is the meaning of the "inlinedAt" argument for DebugLoc::get()? Does it mean the location where the inlined code was defined, or the location where it was expanded? the location where it was expanded - Devang

On Aug 8, 2011, at 10:46 PM, Talin wrote: > So I went ahead and implemented this in my own frontend - I've been using it for both assertions and conditional debug statements. I like it quite a bit, and like you say, it compiles down to nothing in non-debug builds. Does: YOUR_DEBUG_MACRO(…) << some_out_of_line_function(); Still evaluate the out of line function? If so, it seems

So I went ahead and implemented this in my own frontend - I've been using it for both assertions and conditional debug statements. I like it quite a bit, and like you say, it compiles down to nothing in non-debug builds. On Wed, Jul 27, 2011 at 4:00 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Wed, Jul 27, 2011 at 3:31 PM, Talin <viridia at gmail.com> wrote: >

..._AT_byte_size 0 *** DWARF CHECK: DW_AT_decl_file: does not point to valid file info *** DW_AT_decl_file 65 DW_AT_decl_line 6 However, I've double- and triple-checked my code. The code that generates a DIFile looks like this: DASSERT(srcPath.isAbsolute()); DASSERT(dbgCompileUnit_.Verify()); file = dbgFactory_.CreateFile( srcPath.getLast(), srcPath.getDirname(), dbgCompileUnit_); And you can see in the earlier example that I'm passing the generated DIFile to CreateComplexTypeEx. -- -- Talin -------------- nex...

Here are some issues that I am unclear about. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at