[LLVMdev] Next round of DWARF issues/questions

[Talin]

After to speaking to Devang and a number of other people at the developer's
conference, I was able to make some forward progress on getting debugging to
work. I'm now able to actually single-step through my program and set
breakpoints, and examine function parameters.

However, I'm also seeing a lot of new problems which weren't exposed before.
After spending the better part of two days working on them, I'd like to
describe them here and get some advice on what I might be doing wrong.

#1) Class sizes coming out as zero.

In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows:

  DICompositeType di = dbgFactory_.CreateCompositeTypeEx(
      type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type :
dwarf::DW_TAG_structure_type,
      dbgCompileUnit_,
      type->typeDefn()->linkageName().c_str(),
      genDIFile(type->typeDefn()),
      getSourceLineNumber(type->typeDefn()->location()),
      getSizeOfInBits(type->irType()),
      getAlignOfInBits(type->irType()),
      getInt64Val(0), 0,
      DIType(),
      dbgFactory_.GetOrCreateArray(members.data(), members.size()));

The 'getSizeOfInBits()' function and the others like it basically call
llvm::ConstantExpr::getSizeOf() and then multiple the result by 8. Looking
at the generated IR, I can see that the expressions look correct to me (I've
added some line breaks for clarity):

   !15 = metadata !{i32 589826, metadata !2, metadata !"tart.core.Object",
metadata !12, i32 9,
      i64 mul (i64 ptrtoint (%tart.core.Object* getelementptr
(%tart.core.Object* null, i32 1) to i64), i64 8),
      i6 4 mul (i64 ptrtoint (%tart.core.Object* getelementptr ({ i1,
%tart.core.Object }* null, i64 0, i32 1) to i64), i64 8),
      i64 0, i32 0, null, metadata !16, i32 0, null} ; [ DW_TAG_class_type ]

However, when I print out the debugging information via dwarfdump, you can
see that the size of the object is zero:

<1>< 2233>      DW_TAG_class_type
                DW_AT_sibling               <2295>
                DW_AT_name                  tart.core.Object
*                DW_AT_byte_size             0*
                DW_AT_decl_file             65
                DW_AT_decl_line             9
<2>< 2258>      DW_TAG_member
                DW_AT_name                  __tib
                DW_AT_type                  <2228>
                DW_AT_decl_file             65
                DW_AT_decl_line             10
                DW_AT_data_member_location  DW_OP_plus_uconst 0
<2>< 2274>      DW_TAG_member
                DW_AT_name                  __gcstate
                DW_AT_type                  <156>
                DW_AT_decl_file             65
                DW_AT_decl_line             11
                DW_AT_data_member_location  DW_OP_plus_uconst 0

In addition, it appears that all of the field offsets are zero as well - see
the DIEs immediately following the class definition.

#2) I can't seem to get llvm.dbg.declare() to work for local variables,
although it appears to work fine for function parameters. For example, look
at the following snippet of IR:

define {} @ReflectionTest.testModuleReflection(%ReflectionTest* %self) gc
"tart-gc" {
prologue:
  %m = alloca %tart.reflect.Module*
  call void @llvm.dbg.value(metadata !{%ReflectionTest* %self}, i64 0,
metadata !1176)
  call void @llvm.dbg.declare(metadata !{%tart.reflect.Module** %m},
metadata !1177)
  %0 = bitcast %tart.reflect.Module** %m to i8**, !dbg !1178
  call void @llvm.gcroot(i8** %0, i8* null), !dbg !1178


In the debugger, I can examine the value of 'self', however when I attempt
to print the value of 'm', gdb reports 'No symbol "m" in current context.'

#3) When I use the -ka option with dwarfdump, I get tons of errors of the
following form:

<1><  616>      DW_TAG_class_type
                DW_AT_sibling               <791>
                DW_AT_name                  tart.reflect.NameTable
                DW_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101106/7d9575ed/attachment.html>