[LLVMdev] StackColoring remaps debug info from unrelated functions

[Nadav Rotem]

Hi Stefan, 

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 ? 

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,
Nadav

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