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>