TinyCLR的this赋值语句的缘起和解决

鉴客 发布于 2012/03/09 12:08
阅读 101
收藏 0

//=====================================================================
//TITLE:
//    TinyCLR的this赋值语句的缘起和解决
//AUTHOR:
//    norains
//DATE:
//    Wednesday  12-January-2011
//Environment:
//    .Net Micro Framework Porting 4.1
//    MDK V4.0.0
//    VS2010
//=====================================================================

     如果大家辛辛苦苦调试好NativeSample之后,将代码放到TinyCLR进行编译下载,运行时却突然发现莫名崩溃。然后一行一行代码去检查,发现问题居然出在CLR_RECORD_ASSEMBLY header = *this;这个语句。按理说,这个语句不应该出问题啊,究竟是怎么一回事呢?稍安勿躁,我们一起来看看。

 

     追本溯源,我们从LoadKnowAssemblies函数看起,如图:
 

 

     这里有两个变量需要我们注意,分别是TinyClr_Dat_Start和TinyClr_Dat_End。这两个变量是在tinyclr_dat.s中定义的,地址却是和scatterfile_tinyclr_xxx.xml文件有关,如图:
 

 

     我们继续执行LoadKnowAssemblies函数,一直跑到GoodHeader函数,如图:
 

 

     如果再继续往下执行,那么就会引发Hard Fault的错误。是不是很奇怪?我们在仔细看看上面的截图,这时候的this数值为0x0804A001。如果大家是一步步断点进去调试的话,应该知道this指向的地址其实就是TinyClr_Dat_Start地址。但为什么是0x0804A001呢?是不是调试器显示的信息有误?

 

     我们可以打开TinyCLR.map文件,明确地发现,TinyClr_Dat_Start确实是被编译为0x0804A001,如图:


 

     根据scatterfile_tinyclr_xxx.xml文件的配置,TinyClr_Dat_Start不应该是0x0804A001,而应该是0x0804A000才对啊!为什么偏偏多了1个Byte呢?看到这里,你的第一感觉是不是拼命折腾scatterfile_tinyclr_xxx.xml文件?但我很遗憾地说,无论你怎么折腾,TinyClr_Dat_Start的地址永远是%Data_BaseAddress% + 1!

 

     那是不是我们就只能束手无措了呢?也不尽然。其实要修正这地址其实也很简单,只要打开tinyclr_dat.s文件,增加一个SPACE 0语句即可,如图:
 

 

     编译之后会是什么结果呢?我们看看tinyclr.map文件,如图:
 
 
     从图中可以看出,TinyClr_Dat_Start已经和我们设置的一样,变为正确的0x0804A000数值了。

 

     问题是解决了,但让我们回到文章开头,为什么TinyClr_Dat_Start为0x0804A001时,也就是this为0x0804A00时,CLR_RECORD_ASSEMBLY header = *this语句会出现Hard Fault呢?最多也就是拷贝的数据不正确,再怎么着也不应该引发异常吧?

 

     我们进入到汇编代码的层次来查看一下,发现这个赋值语句最后是调用了__rt_memcpy_w函数,如图:


 

     出错的地方在__rt_memcpy_w函数中的LDM语句,如图:


 

     那为什么LDM语句会出现异常呢?我们直接将地址转换为指针,写一些测试代码看看,如图:


 

     这里需要注明的是,测试代码采用memcpy函数,其实最后还是调用了__rt_memcpy_w。从图中看出,__rt_memcpy_w的调用其实是有限制的,也就是说,地址一定要能被4整除,否则一定会产生Hard Fault异常!

 

     回答本文开头的问题其实就简单了。虽然%Data_BaseAddress%我们设置的是0x0804A000,它能够被4整除,但偏偏编译器发了疯,将TinyClr_Dat_Start偏移了1个Byte,变成了0x0804A001,很明显这是一个不能被4整除的数值。而CLR_RECORD_ASSEMBLY header = *this赋值语句最后拿这个不能被4整除的0x0804A001地址来调用__rt_memcpy_w函数,最后肯定就产生了Hard Fault异常。


     最后我们来思考一个很有意思的问题,当TinyClr_Dat_Start被编译为0x0804A001地址时,是不是tinyclr.dat的数据也会往后移1个Byte呢?

 

    我们首先来看看TinyClr_Dat_Start被正确编译为0x0804A000时该区域的数据,如图:


 

     而TinyClr_Dat_Start被错误编译为0x0804A001地址时,数据如下所示:


 

     可以看出,无论TinyClr_Dat_Start是被编译为0x0804A000,还是0x0804A001,tinyclr.dat的数据都是以0x0804A000为起始的!换句话来说,当TinyClr_Dat_Start被编译为0x0804A001时,读取出来的数据肯定是错误的。这算不算是MDK的一个bug呢?


原文链接:http://blog.csdn.net/norains/article/details/6130557
加载中
返回顶部
顶部