请问各位，下面的问题是不是mips编译器的bug？
本帖最后由 haichang417 于 2012-02-17 18:19 编辑函数代码如下：ulong test_function(ulong index,ushort app)
{
_Struct_PST_ID *pstid = NULL;
switch(app)
{
case _MODULE_ID_V:
{
if ( VALIDATE_INDEX( index ) )
{
if( _find_port( g_pstv->member.pstid, index, (void*)&pstid)
== TRUE)
{
return pstid->ulType;
}
}
return SUCCESS;
}
break;
case _MODULE_ID_M:
{
if ( VALIDATE_INDEX( index ) )
{
if( _find_port( g_pstm->member.pstid, index, (void*)&pstid)
== TRUE)
{
return pstid->ulType;
}
}
return SUCCESS;
}
break;
default:
break;
}
return SUCCESS;
}加个赋值NULL后（_Struct_PST_ID *pstid = NULL;）就出现了下面的诡异情况。
下面是用4.3.2交叉编译后的结果：
gcc version 4.3.2 (eCosCentric GNU tools 4.3.2-sw)
(gdb) x0x8017ed5c
0x8017ed5c <test_function+156>: 0x0805fb38
(gdb) disa
disable disassemble
(gdb) disassemble test_function
Dump of assembler code for function test_function:
0x8017ecc0 <test_function+0>:andi a1,a1,0xffff
0x8017ecc4 <test_function+4>:li v0,92
0x8017ecc8 <test_function+8>:beq a1,v0,0x8017ed20 <test_function+96>
0x8017eccc <test_function+12>: addiu sp,sp,-8
0x8017ecd0 <test_function+16>: li v0,93
0x8017ecd4 <test_function+20>: beq a1,v0,0x8017ece8 <test_function+40>
0x8017ecd8 <test_function+24>: sltiu v0,a0,26
0x8017ecdc <test_function+28>: li v0,1
0x8017ece0 <test_function+32>: jr ra
0x8017ece4 <test_function+36>: addiu sp,sp,8
0x8017ece8 <test_function+40>: beqz v0,0x8017ecdc <test_function+28>
0x8017ecec <test_function+44>: lui v0,0x805a
0x8017ecf0 <test_function+48>: lw v1,19204(v0)
0x8017ecf4 <test_function+52>: lw a1,4(v1)
0x8017ecf8 <test_function+56>: beqz a1,0x8017ecdc <test_function+28>
0x8017ecfc <test_function+60>: move v1,a1
0x8017ed00 <test_function+64>: lw v0,4(v1)
0x8017ed04 <test_function+68>: beq a0,v0,0x8017ed5c <test_function+156>
0x8017ed08 <test_function+72>: nop
0x8017ed0c <test_function+76>: lw v1,60(v1)
0x8017ed10 <test_function+80>: bne a1,v1,0x8017ed00 <test_function+64>
0x8017ed14 <test_function+84>: li v0,1
0x8017ed18 <test_function+88>: j 0x8017ece0 <test_function+32>
0x8017ed1c <test_function+92>: nop
0x8017ed20 <test_function+96>: sltiu v0,a0,26
0x8017ed24 <test_function+100>: beqz v0,0x8017ecdc <test_function+28>
0x8017ed28 <test_function+104>: lui v0,0x8067
0x8017ed2c <test_function+108>: lw v1,28060(v0)
0x8017ed30 <test_function+112>: lw a1,4(v1)
0x8017ed34 <test_function+116>: beqz a1,0x8017ecdc <test_function+28>
0x8017ed38 <test_function+120>: move v1,a1
0x8017ed3c <test_function+124>: lw v0,4(v1)
0x8017ed40 <test_function+128>: beq a0,v0,0x8017ed5c <test_function+156>
0x8017ed44 <test_function+132>: nop
0x8017ed48 <test_function+136>: lw v1,60(v1)
0x8017ed4c <test_function+140>: bne a1,v1,0x8017ed3c <test_function+124>
0x8017ed50 <test_function+144>: li v0,1
0x8017ed54 <test_function+148>: j 0x8017ece0 <test_function+32>
0x8017ed58 <test_function+152>: nop
0x8017ed5c <test_function+156>: j 0x8017ece0 <test_function+32>
0x8017ed60 <test_function+160>: lw v0,76(zero)
End of assembler dump.
下面是用3.2.1版本交叉编译后的结果：
gcc version 3.2.1 (eCosCentric GNU tools 3.2.1-sw)
This GDB was configured as "--host=i686-pc-linux-gnu --target=mipsisa32-elf".
For bug reporting instructions, please see:
<http://bugs.ecos.sourceware.org/>...
(gdb) disassemble test_function
Dump of assembler code for function test_function:
0x801748a4 <test_function+0>:addiu sp,sp,-32
0x801748a8 <test_function+4>:andi a1,a1,0xffff
0x801748ac <test_function+8>:li v0,92
0x801748b0 <test_function+12>: sw ra,16(sp)
0x801748b4 <test_function+16>: beq a1,v0,0x80174910 <test_function+108>
0x801748b8 <test_function+20>: sw zero,0(sp)
0x801748bc <test_function+24>: li v0,93
0x801748c0 <test_function+28>: beq a1,v0,0x801748d8 <test_function+52>
0x801748c4 <test_function+32>: sltiu v0,a0,26
0x801748c8 <test_function+36>: li v0,1
0x801748cc <test_function+40>: lw ra,16(sp)
0x801748d0 <test_function+44>: jr ra
0x801748d4 <test_function+48>: addiu sp,sp,32
0x801748d8 <test_function+52>: beqz v0,0x801748cc <test_function+40>
0x801748dc <test_function+56>: li v0,1
0x801748e0 <test_function+60>: lui v0,0x805b
0x801748e4 <test_function+64>: lw v1,20936(v0)
0x801748e8 <test_function+68>: move a1,a0
0x801748ec <test_function+72>: lw a0,4(v1)
0x801748f0 <test_function+76>: jal 0x80174368 <_find_port>
0x801748f4 <test_function+80>: move a2,sp
0x801748f8 <test_function+84>: li v1,1
0x801748fc <test_function+88>: bnel v0,v1,0x801748cc <test_function+40>
0x80174900 <test_function+92>: li v0,1
0x80174904 <test_function+96>: lw v0,0(sp)
0x80174908 <test_function+100>: b 0x801748cc <test_function+40>
0x8017490c <test_function+104>: lw v0,76(v0)
0x80174910 <test_function+108>: sltiu v0,a0,26
0x80174914 <test_function+112>: beqz v0,0x801748cc <test_function+40>
0x80174918 <test_function+116>: li v0,1
0x8017491c <test_function+120>: lui v0,0x8058
0x80174920 <test_function+124>: b 0x801748e8 <test_function+68>
0x80174924 <test_function+128>: lw v1,31260(v0)
End of assembler dump.
在用4.3.2编译器的时候，红色标记部分就出错误。请问是优化过度了，还是编译器的bug？
另外，大家都在使用什么版本的编译器，感觉这两个版本都不尽人意。经常有各种问题出现。谢谢
0x8017ed60 <test_function+160>: lw v0,76(zero)
看起来，是编译器的bug，这里不应该使用zero寄存器。 回复 2# EricFisher
谢谢版主，我觉的也是，太诡异了。不知道这个bug应该怎么避免？ 向工具的开发者发报告，修复bug。不然说不定啥时候就出错了，呵呵。 回复 2# EricFisher
好的。thank U。
页:
[1]