PIC32MZEF上带有XC32 1.40的MPLABX IDE在查看变量时显示超出范围消息

我看到这个thordHTTP://www. McCHIP.COM/FUMUS/M937 116.ASPX，NKurZman建议移动到MPLABX V3.35。不幸的是，我已经使用3.35了。另外，这个线程中的带属性的函数编译技巧对于任何优化级别都不适用。



      以下为原文

    I see this thread http://www.microchip.com/forums/m937116.aspx where NKurzman advises moving to MPLABX v3.35.  Unfortunately, I am using 3.35 already.
 
In addition, the function compile-with-attribute trick in that thread doesn't work for me for any optimization level.

在THealthHTTP://www. McClob/com /Mux36126.ASPX 936196中对此进行了大量的确认。我确认将变量声明为函数范围（“局部”），但“易失性”不能解决问题。但是，将变量声明为文件范围（“全局”）确实解决了问题。RayLead，但是是一个KLUKE解决方案，我当然不想为所有已经消失的函数范围变量做这个。保罗



      以下为原文

    Much activity on this in the thread http://www.microchip.com/forums/m936126.aspx#936196 .
 
I confirm that declaring the variable as function scope ("local", kind of) but "volatile" DOES NOT RESOLVE the problem. 
 
However, declaring the variables as file scope ("global") DOES resolve the problem in a temporary sense, but is a kludge solution and I certainly don't want to do this for ALL of my function scope variables that have disappeared.
 
Paul

在“超出范围”问题开始出现之后：似乎可以使用“local”声明中的“volatile”强制块范围（在最里面的{}）变量出现。然而，将已知值赋值给变量会出现错误的值，如所报告的那样。可见文件作用域变量的后续赋值语句显示预期值，与块作用域变量中报告的值不同。例如：int aFileScopeVariable;void foo(void){{{volatile int aBlockScopeVariable;aBlockScopeVariable=5;a BlockScopeVariable=5;出现在手表窗口中奇怪的东西。在监视窗口中显示为5或通过悬停ASM（“NOP”）；/ /断点在这里}



      以下为原文

    After this "Out of Scope" problem starts happening:
 
It seems that block scope (within the innermost {}) variables can be forced to appear using "volatile" in the "local" declaration.  However, assigning a known value to the variable appears to result in an incorrect value, as reported.  A subsequent assignment statement to a visible file scope variable show the expected value, different than what was reported to be in the block scope variable.  For rough example:
 
int aFileScopeVariable;
 
void foo(void)
{
     {
          volatile int aBlockScopeVariable;
          aBlockScopeVariable = 5;     // aBlock... shows up as something strange in the watch window
          aFileScopeVariable = aBlockScopeVariable;     // aFile... shows up as 5 in the watch window or by hovering
 
          asm("nop");     // breakpoint here
     }
}

使用MPLAB X 3.35和XC32 v1.42，即使从BlockScopeVariable中删除易失性限定符，您上面的示例也没有问题。我使用了PIC32 MZ0512EFE064和XC32 V1.40是黄灯状态。无法使用该设备编译简单示例。我搬到XC32 V1.42。请参阅附件屏幕截图。也许您的项目有更多的复杂性。您可以附加ELF文件，并给出PC的位置，其中变量是不可解析的。当做，



      以下为原文

     
 
I can find no issue with your above example using MPLAB X 3.35 and XC32 v1.42 even removing the volatile qualifier from aBlockScopeVariable.  I used a PIC32MZ0512EFE064 and XC32 v1.40 was yellow light status. I could not compile the simple example using that device.  I moved to XC32 v1.42.  See attached screen shot.
 
Maybe your project has more complexity.  Can you attach the ELF file and give PC locations where variables
are not resolvable.   
 
Regards,
 
 
   Attached Image(s)

谢谢你的检查，Melice。我把代码段作为一个粗略的例子。它意在表明，在这种罕见的情况下，IDE认为变量在作用域中，但是它不在作用域中，因为在监视窗口中报告了错误的值。控制器实际上在下面做正确的事情，但是回到原来的问题。该项目非常大，工作在自定义板上，因此它不会运行到变量在模拟中不能解析的程度。但我想你还是有工具来诊断这个问题的。这里是：尝试程序定位0x9D0667 E0。变量esoutgoingCommandincomingCommandResponse的作用域是包含这个位置的函数APP_BtleTasks()，但是没有显示。稍后退一步，该作用域在程序流期间在点0x9D006520之后消失，至少在这个特定的构建之前或者从switch语句跳转到0x9D00610C到0x9D00657C。对于一些构建，它发生在其他地方，但是总是可重复的。虽然它们是重复使用的，但它们也不再显示在范围内。附件是ELF文件。我可以假设这是安全的和专有的吗？如果没有，请将其脱机。为了调试目的，我将这些变量移到文件范围，问题就解决了，所以暂时不会阻止我。但我不想依赖这个解决方案。保罗



      以下为原文

    Thanks for checking, mellis.
 
I meant that code section as a rough example.  It is meant to show that in this rare instance the IDE thinks that a variable is in scope, but it is not, since the wrong value is reported in a watch window.  The controller is actually doing the right thing underneath that.
 
But back to the original problem.  The project is quite large, works on a custom board, and because of that it won't run to the point that variables are not resolvable on simulation.  But I guess that you have tools to diagnose the issue anyway.  So here goes:  try program location 0x9D0067E0.  The variables outgoingCommand and incomingCommandResponse are scoped to the function APP_BtleTasks() containing this location, but don't show up.
 
Stepping back a bit, the scope disappears during program flow somewhat after the point  0x9D006520 and, at least for this particular build, immediately before or at the jump from the switch statement jump at 0x9D00610C to 0x9D00657C.  For some builds it happens elsewhere, but it is always repeatably.  Neither show up as in scope ever again, though they are used repeatably.
 
Attached is the ELF file.  May I assume that this is secure and proprietary?  If not, please pull it offline.
 
For debugging purposes, I move these variables to file scope and the problem goes away, so this isn't stopping me for the time being.  But I don't want to rely on this fix.
 
Paul

对于所有编译器来说，这是一个常见的解决方案。当您需要它们时，您可以进行调试并在完成时恢复它们。编译器应该是优化的。变量被移动到寄存器中，或者永远不会存在于程序中。这就是编译器所期望的。不过，我相信编译器的ELF文件或MPLABX并不总是显示变量。但是除非你有一个很好的例子来观察微芯片，否则它无法被修复。验证V3.40中仍然存在的问题。不要把所有事情都变成一种波动，除非你不在乎你的程序是大而慢的。



      以下为原文

    That is a common fix for all compilers. You do it while you need them for debugging and restore them when you are done.
The compiler is optimizing, as it should. Variables are moved to registers, or never exist in the program. It is what one expects from a compiler.
However I do believe there are issues with the compiler elf file or MPLabX that does not always show variables. But unless you have a good simple example for microchip to look at, it can not get fixed.

Verify the issue still exists in v3.40.
And do not make everything gloabal an volatitle unless you do not care that your program is big and slow.

大家好，我已经确定XC32编译器正在生成一个新的GNU位置列表操作代码扩展，MPLAB X调试器目前无法理解它。操作码通常描述变量的值仍然驻留在cpu寄存器中，在函数输入时该值位于该寄存器中。在变量的值不会超过某一点的情况下，变量被认为不存在。就像在不需要位置访问的地方替换常量一样。不过，我正在添加支持，以便MPLAB X调试器能够解码并显示CPU寄存器值，只要位置范围表明它是有效的。关于这一点，另一个令人误解的地方是，状态应该被指示为“由编译器优化”，而不是“超出范围”，这在本例中更远离标记。这很不幸，因为导致这种位置信息的寄存器使用与优化有关。我想强调的是，MPLAB X位置列表解码用于XC32在大多数情况下是非常好的，即使值随着您的步骤从一个cpu寄存器位置移动到另一个cpu寄存器位置。不幸的是，它只需要一个丢失解码导致怀疑成立。这个问题很可能与你的处境有关。我要求精灵文件只验证这一个OP代码扩展实际上也是你的问题的原因。我为失去的支持道歉，并将很快添加它。谢谢，



      以下为原文

    Hi guys,
 
I have determined that the XC32 compiler is generating a new GNU location list op code extension that is currently not understood by the MPLAB X debugger.   The opcode generally describes that a value for a variable is still residing in a cpu register where it was located upon entry to the function.  In cases where the value for the variable won't change beyond a certain point,  the variable is considered to not really exist.  Like when constant is substituted where location access does not need to happen.
 
Still, I am in the process of adding support so that MPLAB X debugger will be able to decode and show the CPU register value as long as the location scope indicates it is valid.   The other misleading thing about this is that the status should have been indicated as "optimized by compiler" rather than "out of scope" which is farther from the mark in this case.   That was unfortunate since register use which results in this kind of location information is optimization related.  
 
I do want to emphasize that MPLAB X location list decoding for XC32 is very good most of the time even when values are moved from one cpu register location to another as you step.  Unfortunately it only takes one missing decode to cause doubt to set in.  This issue is very likely related to your situation.  I had asked for the ELF file only to verify that this same op code extension is actually the cause of your problem too.  I apologize for the missing support and will get it added very soon.  
 
Thanks,

谢谢你，mellis！在添加对这个新编译器扩展的支持的过程中，最好的祝愿。我假设这将被添加到MPLABX IDE，而不是XC32编译器，对吗？在发行说明中，这将被称为“新GNU位置列表OP代码扩展”的支持吗？你预计这个加法的前置时间是几周还是几个月？在把这些变量保持在文件范围内的KLUKE修复中，我并不着急。保罗



      以下为原文

    Thank you, mellis!
 
Best wishes in the process of adding support for this new compiler extension.  I assume that this will be added to the MPLABX IDE, not the XC32 compiler, correct?  Will this be noted as support for a "new GNU location list op code extension" in the release notes?  Do you expect the lead time for this addition will be weeks, or months?  With the kludge fix of keeping these variables in file scope, I'm not in a huge hurry.
 
Paul

他们似乎在一个大约四的发布一年的时间表。



      以下为原文

    They seem to be on an approximately four release a year schedule.

对GNU扩展的支持将添加到MPLAB X.FWIW中，编译器将生成对DWARF位置列表计算方法的GNU扩展，DWARF 4规范中定义了这种方法。我已经添加了这个变化的支持，并且修复将使它进入MPLAB V3.45发布测试周期。-）我希望这种缺少的支持是你的问题的原因，并且当项目发布时，本地变量位置跟踪将改进3.45版。目前正在发布候选测试阶段。所以它应该在接下来的几周内出来。当做，



      以下为原文

     
Support for the GNU extension I explained previously will be added to MPLAB X. FWIW, the compiler is generating a GNU extension to DWARF location list calculation methods which is defined in the DWARF 4 specification.  I have added the support for this variation and the fix will make it into the MPLAB X v3.45 release test cycle. ;-)
 
I hope that this missing support was the cause of your issue and that local variable location tracking in your project
will be improved by v3.45 when it is released.  It is currently in release candidate testing stage.  So it should be out in the next couple of weeks.  
 
Regards,

谢谢你跟踪这个问题。你知道当Microchip团队MeMeBeS写下它将在下一个版本（没有日期）或者将来发布时，它通常没有什么帮助。大多数项目不能等待3个月，希望它可能是固定的。如果不是的话。



      以下为原文

   
Thank you for tracking the issue.
You know when the microchip team memebers write it will be in the next release(no date) or a future release it is usually of little help. Most projects can not wait upto 3 months on the hope that it might be fixed. Then again if it was not.