[LLVMdev] More DIFactory questions - still stumped

[Talin]

On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote:

> 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
> parameter
> > in a function type descriptor, but according to a code search, the name
> > "DW_TAG_formal_parameter" does not appear anywhere in the clang source
> code.
> > Instead, the argument array that is used when creating a function type
> > descriptor contains only the bare types, not types wrapped in a formal
> > parameter DIE.
>
> Hi Talin,
>
> Like in CGDebugInfo, you have to use the Subprogram type only for the
> return type. What gives you the parameters is passing the Function* as
> the last parameter on DIFactory.CreateSubprogram().
>

I understand about passing the Function* as the last argument. I'm not sure
I understand the first sentance ("You 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_.CreateSubprogram(
        dbgCompileUnit_,
        fn->name(),
        fn->qualifiedName(),
        fn->linkageName(),
        dbgFile_, // genDIFile(fn),
        1, // getSourceLineNumber(fn->location()),
        dbgFuncType,
        fn->isSynthetic() /* isLocalToUnit */,
        false /* isDefinition */,
        0, 0 /* VK, Index */,
        DIType(),
        false /* isArtificial */,
        false /* isOptimized */,
        f);
    DASSERT(sp.Verify());
  }


  return sp;
}


And here's the code that generates function type descriptors:

DICompositeType CodeGenerator::genDIFunctionType(const FunctionType * type)
{
  DIDescriptorArray args;
  args.push_back(genDIType(type->returnType()));

  if (type->selfParam() != NULL) {
    const ParameterDefn * param = type->selfParam();
    // genDIParameterType() calls genDIType and then makes it a pointer
    // if the underlying type is a reference type.
    args.push_back(genDIParameterType(param->type()));
  }

  const ParameterList & params = type->params();
  for (ParameterList::const_iterator it = params.begin(); it !=
params.end(); ++it) {
    const ParameterDefn * param = *it;
    args.push_back(genDIParameterType(param->type()));
  }

  DICompositeType fnType = dbgFactory_.CreateCompositeType(
      dwarf::DW_TAG_subroutine_type,
      dbgCompileUnit_,
      "",
      dbgFile_,
      0, // Source line
      0, // Size
      0, // Align
      0, // Offset
      0, // Flags
      DIType(),
      dbgFactory_.GetOrCreateArray(args.data(), args.size()));

  dbgTypeMap_[type] = fnType;
  DASSERT(fnType.Verify());
  return fnType;
}



I suppose DIFactory was done tailored to C-like languages using Clang
> as the primary driver for changes. I'd not be surprised if you could
> do things that it didn't expect and then it'd generate images with bad
> Dwarf (enough to cause segfault in dwarfdump).
>
> I'd try to mimic exactly what CGDebugInfo does, even if that makes
> your "info func" look like C functions in GDB, or if the parameters
> are all mixed up. At least you get something out of it and can, then,
> work your way to fix it in LLVM.
>
> I'm putting together some help with using DIFactory, maybe I can turn
> that into a proper doc. I'll keep you posted.
>
> --
> 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/20100905/64d18182/attachment.html>