[LLVMdev] StackColoring remaps debug info from unrelated functions

[Stefan Hepp]

On 2013-09-30 05:42, Nadav Rotem wrote:
> This looks like a bug. Thanks for catching this and writing the
> mailing list.  Do you think you could submit a patch to fix the
> problem ?
>

Not sure .. I tried to add the following line to the loop:

     if (Var->getFunction() != MF->getFunction()) continue;

.. but it does not seem to work. In my test case no debug variables are 
remapped anymore, so MDNode::getFunction() does not seem to do what I 
need.. need to check. It is probably necessary to get the lexical scope 
from the DebugLoc of the variable and compare this to the function, but 
I don't understand the scopes in LLVM sufficently (yet) to do this. So 
any help/info on this is greatly appreciated..


> I understand that you can’t release your source code, but there is an
> easy way to generate test-cases from confidential code.  If you can
> write a “verifier" that makes the compiler crash on an assertion then
> you can use bug point to reduce your test case. You don’t need to
> actually commit the verifier, just the reduced test case.
>

Thanks, I will give it a try.. I might also be able to create a test 
case based on the StackColoring tests in the X86 CodeGen test folder.

Kind regards,
  Stefan


> On Sep 29, 2013, at 1:40 PM, Stefan Hepp <stefan at stefant.org> wrote:
>
>> Hi,
>>
>> I run into a a strange error when compiling with debug infos, where
>> LLC tries to generate a variable DIE using a completely wrong
>> frame-index (DebugDwarf tries to resolve frame index 27 in a simple
>> function which only has a single frame object .. ).
>>
>> After digging around, I found that MachineModuleInfo has a
>> VariableDbgInfo map, that is filled by SelectionDAGBuilder.
>> MMI->VariableDbgInfo maps MDNodes representing variables to a
>> <FrameIndex, DebugLoc> pair. All infos of all functions reside in a
>> single map per module.
>>
>> In lib/CodeGen/StackColoring.cpp:493 is the only place where this
>> information is updated (I am using LLVM 3.3, but the code seems to
>> be the same in trunk).
>>
>> StackColoring::remapInstructions(DenseMap<int, int> &SlotRemap):
>>
>> // Remap debug information that refers to stack slots.
>> MachineModuleInfo::VariableDbgInfoMapTy &VMap =
>> MMI->getVariableDbgInfo(); for
>> (MachineModuleInfo::VariableDbgInfoMapTy::iterator VI =
>> VMap.begin(), VE = VMap.end(); VI != VE; ++VI) { const MDNode *Var
>> = VI->first; if (!Var) continue; std::pair<unsigned, DebugLoc> &VP
>> = VI->second; if (SlotRemap.count(VP.first)) {
>> DEBUG(dbgs()<<"Remapping debug info for
>> ["<<Var->getName()<<"].\n"); VP.first = SlotRemap[VP.first];
>> FixedDbg++; } }
>>
>>
>> Note that this iterates over all VariableDbgInfos of all functions
>> (since it is a Machine*Module*Info), but it only checks if the
>> frame index matches, not if Var is actually in the current
>> MachineFunction.
>>
>> This causes the StackColoring pass to change the frame index from 0
>> to 27 in my simple small function due to some optimisation in a
>> completely unrelated large function.
>>
>> This doesn't seem right .. so either I am missing something here,
>> or this loop is missing some code to check if the variables
>> actually belong to the current MF. I don't really know how to do
>> this check though..
>>
>> (I have not been able to create a simple testcase that triggers
>> this code though, and I cannot share the code on which it fails as
>> it is not open..)
>>
>> Kind regards, Stefan
>> _______________________________________________ LLVM Developers
>> mailing list LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>