[LLVMdev] DIBuilder - what's with the null compile units?

[Talin]

On Fri, Oct 28, 2011 at 9:21 AM, Devang Patel <dpatel at apple.com> wrote:

>
> On Oct 27, 2011, at 10:39 PM, Talin wrote:
>
> On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote:
>
>>
>> On Oct 23, 2011, at 12:03 AM, Talin wrote:
>>
>> Just a follow up on this - I am still having problems, I never did figure
>> out a solution. (I've been running with debug off for the last month so
>> that I could get work done.)
>>
>> Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I
>> even put a debug print statement right after it, so that I could be sure
>> that the code was being executed. I also insured that it was getting called
>> before the module was written out, and that no additional debug information
>> gets added after it has been called.
>>
>> Yet despite this, the second-to-last parameter for DW_TAG_subprogram
>> metadata is in fact null in the module dissassembly.
>>
>> So essentially I am completely stumped.
>>
>>
>> If you're using DIBuilder to create your subprogram then you'll see that
>> it puts new node in AllSubprograms.
>>
>>   // Create a named metadata so that we do not lose this mdnode.
>>
>>
>>   AllSubprograms.push_back(Node);
>>
>> And follow AllSubprograms in DIBuilder::finalize()
>>
>> I traced through the code in DIBuilder::finalize():
>
>   *for* (*unsigned* i = 0, e = SPs.getNumElements(); i != e; ++i) {
>     DISubprogram SP(SPs.getElement(i));
>     *if* (NamedMDNode *NMD = getFnSpecificMDNode(M, SP)) {
>       SmallVector<Value *, 4> Variables;
>       *for* (*unsigned* ii = 0, ee = NMD->getNumOperands(); ii != ee; ++ii)
>
>
> It looks as if getFnSpecificMDNode() is always returning NULL in my case -
>  the body of the if statement never gets executed.
>
>>
> The two lines above this for loop is
>
>   DIArray SPs = getOrCreateArray(AllSubprograms);
>   DIType(TempSubprograms).replaceAllUsesWith(SPs);
>
> This should populate your CompieUnit's   node that holds top level
> subprograms.
> -
> Devang
>
> I created a bug (http://llvm.org/bugs/show_bug.cgi?id=11271) with some
small example files that demonstrate the problems I am having. At this
point I do not know whether the problem is in my frontend or in llc. An
examination of the samples I uploaded might be able to determine at least
that much: If the bitcode is correct, then it's a problem with llc; If the
bitcode is wrong, then it's a problem in my frontend.

I've been attempting to trace through DIBuilder::finalize() in the debugger
in order to determine what might be going wrong. Unfortunately, the code in
that section is not easy to debug, because the various collection classes
involved aren't very easy to examine in the debugger. (For example, it's
hard to see in the debugger what the effect of replaceAllUses... is.)

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