[LLVMdev] More DIFactory questions - still stumped

[Devang Patel]

If llvm compiler mis compiles a code then it is unlikely to be a bug in IRBuilder. Most likely it could be a bug in FE's use of IRBuilder or codegen/optimization bug. In either case IRBuilder won't save you. Same is true for DIFactory. It is a utility to construct MDNodes. It does not strictly enforce semantic correctness of debug info. (In fact, it is on my list somewhere to absorb DIFactory into IRBuilder). BTW, DIFactory should be independent of a debugging format used by code generator. But until a target that implements format other than DWARF arrives, this remains theory only.

In your case, most likely you're running into a bug in DwarfDebug (or your encoding is violating hidden assumptions made by DwarfDebug, which is also not good.) Your best bet is to reduce the test case as much as possible and watch DIEs (DIE.cpp). I have seen this symptom once where a constructed DIE was not emitted in the end due to a bug.

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.

-
Devang
On Sep 7, 2010, at 8:34 AM, Talin wrote:

> On Tue, Sep 7, 2010 at 1:56 AM, Renato Golin <rengolin at systemcall.org> wrote:
> On 6 September 2010 01:05, Talin <viridia at gmail.com> wrote:
> > DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn,
> (...)
> >         false /* isDefinition */,
> (...)
> 
> Hi Talin,
> 
> The only difference from what I'm doing is that I only export debug
> symbols in definitions, not declarations. I may be doing wrong,
> though, for multi-file compilation (haven't tested thoroughly).
> 
> 
> 
> > DICompositeType CodeGenerator::genDIFunctionType(const FunctionType * type)
> (...)
> >   for (ParameterList::const_iterator it = params.begin(); it !=
> > params.end(); ++it) {
> >     const ParameterDefn * param = *it;
> >     args.push_back(genDIParameterType(param->type()));
> >   }
> 
> Don't do that. I know it looks right, but it's broken in DIFactory.
> 
> 
> >   DICompositeType fnType = dbgFactory_.CreateCompositeType(
> >       dwarf::DW_TAG_subroutine_type,
> >       dbgCompileUnit_,
> 
> I use the file here, not the compile unit... But again, I could be wrong.
> 
> Hope that puts you in the right direction.
> 
> OK I made 3 changes:
> -- changed isDefinition to true. (I'm also only generating debug info for definitions.)
> -- commented out the code that pushes parameter types to the arg list. (Still push the return type however.)
> -- changed the call that creates the subroutine type to use DIFile rather than DICompileUnit as the context param.
> 
> It still segfaults however. :(
> 
> I should mention that I don't actually know if the CreateSubprogram call is even related to the problem. I know that when I comment out the call, the segfault goes away - however, that just might mean that the problem is still there but is not being triggered. 
> 
> I have to admit I am rather confused about the proper usage of DIFile and DICompileUnit. Both of these are DIScopes, but it's not clear to me whether the symbols within a module should be the children of one or the other. Many of the DIFactory parameters take an explicit DIFile, so those cases are clear - but many of the other context params only have DIDescriptor as their type, so there's not a lot of guidance as to which is the right type of DIDescriptor to use.
> 
> --
> cheers,
> --renato
> 
> http://systemcall.org/
> 
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
> 
> 
> 
> -- 
> -- Talin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100907/a9c96a91/attachment.html>