[LLVMdev] "Cannot fine DIE"

[Talin]

On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote:

> On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote:
>
>>
>> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote:
>>
>>> I recently started getting this error when I try to debug my
>>> LLVM-compiled program in GDB:
>>>
>>>     Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at
>>> 0x1713c [in module
>>> /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest]
>>>
>>> I'm not sure if it's something I did or not. Is there any way to track
>>> down the cause of this error? The hex addresses in the error message are
>>> meaningless to me.
>>>
>>
>> There is not much info here. The error says one debug info entry (DIE) is
>> referring to another debug info entry that does not exist. This usually
>> indicates that dwarf generator in llvm codegen knew about the other DIE but
>> some how gdb does not find the DIE. May be the code generator did not emit
>> the DIE ? If yes then why ?  Otherwise, the DIE was dropped somewhere after
>>  compiler generated code.
>>
>> I've discovered a little bit more, but not enough to solve the problem.
>
> Here's what my code looks like for setting the debug location (some details
> removed for clarity):
>
> void CodeGenerator::setDebugLocation(const SourceLocation & loc) {
>   if (loc != dbgLocation_ && dbgContext_.isScope()) {
>     dbgLocation_ = loc;
>     if (loc.file == NULL) {
>        builder_.SetCurrentDebugLocation(llvm::DebugLoc());
>     } else if (loc.file == module_->moduleSource()) {
>       TokenPosition pos = tokenPosition(loc);
>       // ** Comment out this line and the DIE errors disappear **
>       builder_.SetCurrentDebugLocation(
>           DebugLoc::get(pos.beginLine, pos.beginCol, dbgContext_));
>     }
>   }
> }
>
> As noted in the comment above, if I comment out the line that calls
> builder_.SetCurrentDebugLocation(), then gdb no longer reports not being
> able to find the DIE. Of course, I don't get any source-line debugging
> information either.
>
> Note that even in this case, I'm still generating tons of DWARF info for
> data types, files, functions, and so on. This all apparently works (or at
> least, it doesn't seem to generate this particular problem). It's only the
> generating of source line information that causes the error. This is
> fortunate, since as you can see the code is quite trivial, whereas I was
> afraid that if the problem was in the data type code, it would take forever
> to locate the problem as that code is pretty complicated.
>
> As far as why this code is causing the error, I can only guess that I am
> calling it wrong somehow. But I can't think what I could do differently from
> what I am doing already.
>

OK some progress on this: Changing the 'scope' argument passed to
DebugLoc::get() - from a DICompileUnit to a DIFile (I'm not sure which is
right, the docs and comments aren't real clear on this) - gets rid of the
"Can't find DIE" error. Instead I get:

    "Line number -1 out of range;"

...when I try to examine a stack frame. Which is strange, because  *know* my
line numbers are not -1. There's even an assert for that. And the comments
in my generated assembly language look perfectly valid to me:

Ltmp26:
        subl    $8, %esp                ## Array.tart:103:11[
Array.tart:103:11 ]
Ltmp27:                                 ## Array.tart:103:11[
Array.tart:103:11 ]
        movl    $0, 4(%esp)             ## Array.tart:103:11[
Array.tart:103:11 ]
        movl    $16, (%esp)             ## Array.tart:103:11[
Array.tart:103:11 ]
        call    _malloc                 ## Array.tart:103:11[
Array.tart:103:11 ]


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