Arm Xscale不正确的分支 [英] Arm Xscale incorrect branch

问题描述

我正在开发arm xscale嵌入式系统。在这里，我看到一个不正确的分支在开关盒中被执行。



下面是我的开关盒看起来像，

 开关（val）
 {
  case   0 ：
 .... 
  break ; 
  case   1 ：
 .... 
 断裂; 
  case   2 ：
 ..... 
 断裂; 
  case   3 ：
 ..... 
 断裂; 
 默认：
 printf（ 案例值=％d \\\\ n，val）; 
  break ; 
} 

在上面的例子中，我收到零值，即val = 0.

但是cpu分支到默认情况，我打印了值，它只显示零。 案例值= 0。看起来很奇怪。

Break语句是正确的。 val是一个带符号的int（没问题）。

我试图理解为这个switch case块生成的汇编，但是我不理解生成的汇编指令中使用的逻辑。

我不认为汇编程序生成错误的程序集（可能我不知道）。是否有任何可能的硬件错误会导致MMU或TLB中出现类似问题，指令缓存奇偶校验问题或任何其他事情？如何调试此问题？

解决方案

硬件错误是不太可能的。它可能是编译器错误。您可以在switch语句前放置另一个print语句，以确保该值为零。



要确认编译器错误，必须检查生成的汇编代码。您可以编辑您的问题并添加它。也许这里有人可以验证它。



另一种选择是禁用所有编译器优化。如果行为发生变化则表明存在编译器错误。



另一个有趣的测试是使用另一个变量，该变量用值初始化并将其传递给switch语句。

I am working on arm xscale embedded system. Here I am seeing a incorrect branch is getting executed in switch case.

Below is my switch case looks like,

switch(val)
{
  case 0:
         ....
         break;
  case 1:
         ....
         break;
  case 2:
         .....
         break;
  case 3:
         .....
         break;
  default:
         printf("case value = %d\r\n" ,val);
         break;
}

In the above case , I am receiving value as zero i.e val = 0.
But the cpu branches to default case, where i have printed the value, which is showing zero only. "case value = 0". Looks very strange.
Break statements are proper. "val" is a signed int(no problem there).
I have tried to understand the assembly generated for this switch case block, but I don't understand the logic used in the generated assembly instructions.
I don't think wrong assembly was generated by assembler(may be I don't know).Is there any possiblity of hardware bug which will create this kind of problem like issues in MMU or TLB , instruction cache parity issues or any other thing ?How to debug this issue?

解决方案

A hardware bug is very unlikely. It may be a compiler bug. You may put another print statement in front of the switch statement to ensure that the value is zero there.

To confirm a compiler bug the generated assembler code must be checked. You may edit your question and add that. Maybe someone here can verify it.

Another option would be disabling all compiler optimisations. If the behaviour changes it indicates a compiler bug.

Another interesting test would be using another variable which is initialised with the value and passing that to the switch statement.

这篇关于Arm Xscale不正确的分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！