llvm dev - Sep 2013 - [LLVMdev] StackColoring remaps debug info from unrelated functions

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

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

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