CE5.0下如何生成.cod文件?

gsymichael 2008-10-21 04:01:50
如题,如何生成.cod文件?
在通过PB帮助和上网查资料,都说是Set WINCECOD=1之后重新Build。
可是我按这个方法Build驱动,为什么没法生成.cod文件。
那位生成过的介绍一下方法啊。
...全文
345 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
gooogleman 2008-10-22
  • 打赏
  • 举报
回复
我现在马上试试
gsymichael 2008-10-22
  • 打赏
  • 举报
回复
[Quote=引用 9 楼 songtitan 的回复:]
我一直可以的,设置好环境变量后build,然后在obj目录下就是大把的cod了
[/Quote]
如何设置呢?只是简单的设WINCECOD=1就可以了吗?
还需要设置其他的什么吗?
songtitan 2008-10-22
  • 打赏
  • 举报
回复
我一直可以的,设置好环境变量后build,然后在obj目录下就是大把的cod了
gooogleman 2008-10-22
  • 打赏
  • 举报
回复
the COD file from obj\%_TGTCPU%\%WINCEDEBUG%. ----------如果没有,那估计真有问题了。有些文件是搜索不到的。
gsymichael 2008-10-22
  • 打赏
  • 举报
回复
不是和.obj在一个目录下吗?我看了没有。而且用搜索文件找也没有
gooogleman 2008-10-22
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 gsymichael 的回复:]
你说的那个Blog我也看到过,就是按上面的去试的。发现无法生成.cod文件。
后来看帮助文档,也就说是set WINCECOD=1。 不过这个值实际上默认就是设
为1的。也没有发现有对应的.cod生成。郁闷。
[/Quote]

会不会是你没有找对生成的路径?
gsymichael 2008-10-22
  • 打赏
  • 举报
回复
你说的那个Blog我也看到过,就是按上面的去试的。发现无法生成.cod文件。
后来看帮助文档,也就说是set WINCECOD=1。 不过这个值实际上默认就是设
为1的。也没有发现有对应的.cod生成。郁闷。
gooogleman 2008-10-22
  • 打赏
  • 举报
回复
Platform Builder: Find the Source of a Data Abort; an Example http://geekswithblogs.net/BruceEitman/archive/2008/06/02/platform-builder-find-the-source-of-a-data-abort-an.aspxPreviously I posted instructions for finding the source of a data abort, see Windows CE: Finding the cause of a Data Abort. This will walk through those steps to find the source in a real application for. This is specific to Windows CE and later.

I have this data abort:

AKY=00000005 PC=02c138ac(lan91c111.dll+0x000038ac) RA=02c138a8(lan91c111.dll+0x000038a8) BVA=06000000 FSR=00000007

From this, I can see that it is in lan91c111.dll. Lan91c111.dll is my Ethernet driver. I was just making changes to it, so I could go back and review my changes for hints. But let's find it from the Data Abort output.

We can also see that the Return Address (RA) is at 0x000038a8
Subtract 0x1000 to find the Module Offset(MO) of 0x000028a8
We can now look up the Module Offset in lan91c111.map. Here is a small section of lan91c111.map:

Address Publics by Value Rva+Base Lib:Object
0001:00002780 READ_ETH_USHORT_32BIT_MODE 10003780 f LAN91C111_Init.obj
0001:00002798 WRITE_ETH_USHORT_32BIT_MODE 10003798 f LAN91C111_Init.obj
0001:000027cc WRITE_ETH_CUSTOMIZE_USHORT 100037cc f LAN91C111_Init.obj
0001:00002820 LAN91C_Write16 10003820 f LAN91C111_Init.obj
0001:00002884 LAN91C111_MiniportInitialize 10003884 f LAN91C111_Init.obj
0001:00002fc4 LAN91C111_MiniportISR 10003fc4 f LAN91C111_Intr.obj

Looking at the addresses we find that the MO is between 00002884 LAN91C111_MiniportInitialize and 00002fc4 LAN91C111_MiniportISR. That tells us that the Data Abort occurred in LAN91C111_MiniportInitialize. To calculate the Instruction Offset(IO) subtract the Function Offset(FO) from the Module Offset: 0x00002858 - 0x00002884 = 0x28.
The file that contains LAN91C111_MiniportInitialize is Lan91C111.c, which we know because of the name of the object file that the function is in. But, what we need is the COD file, which contains the C code as comments mixed with the assembly code that was created when the file was compiled. The COD files are in the same folder that the OBJ files are in. If you don't have the COD files, set WINCECOD=1 and rebuild.
Looking in the COD file, find the function; in this case LAN91C111_MiniportInitialize. This is what mine looks like:

00000 AREA |.rdata| { |??_C@_1BC@ECFINIDN@?$AA?$CK?$AAp?$AAt?$AAr?$AA?5?$AA?$CF?$AAX?$AA?6?$AA?$AA@| }, DATA, READONLY, SELECTION=2 ; comdat any
|??_C@_1BC@ECFINIDN@?$AA?$CK?$AAp?$AAt?$AAr?$AA?5?$AA?$CF?$AAX?$AA?6?$AA?$AA@| DCB "*"
DCB 0x0, "p", 0x0, "t", 0x0, "r", 0x0, " ", 0x0, "%", 0x0, "X"
DCB 0x0, 0xa, 0x0, 0x0, 0x0 ; `string'
; Function compile flags: /Ogsy
00000 AREA |.text| { |LAN91C111_MiniportInitialize| }, CODE, ARM, SELECTION=1 ; comdat noduplicate
00000 |LAN91C111_MiniportInitialize| PROC
; 144 : {
00000 |$L48878|
00000 e92d47f0 stmdb sp!, {r4 - r10, lr}
00004 e24dd054 sub sp, sp, #0x54
00008 |$M48876|
00008 e1a06003 mov r6, r3
0000c e1a04002 mov r4, r2
00010 e1a07001 mov r7, r1
; 145 : NDIS_STATUS Status = NDIS_STATUS_SUCCESS;
; 146 : UINT ArrayIndex;
; 147 : PMINIPORT_ADAPTER Adapter;
; 148 : USHORT temp;
; 149 :
; 150 : LPVOID lpIOBase;
; 151 : BOOL RetVal;
; 152 : DWORD *ptr = NULL;
; 153 : WCHAR szFunctionName[] = L"LAN91C111_MiniportInitialize()";
00014 e59f1720 ldr r1, [pc, #0x720]
00018 e28d0014 add r0, sp, #0x14
0001c e3a0203e mov r2, #0x3E
00020 eb000000 bl memcpy
; 154 :
; 155 :
; 156 : RETAILMSG( 1, (TEXT("*ptr %X\n"), *ptr ));
00024 e3a03000 mov r3, #0
00028 e5931000 ldr r1, [r3]
0002c e59f0704 ldr r0, [pc, #0x704]
00030 eb000000 bl NKDbgPrintfW

The numbers on the left of the assembly code are the Function Offsets, and we can see that at offset 0x28 we have:

00028 e5931000 ldr r1, [r3]

Which is dereferencing an indirect address which we can see is the *ptr in the C code above it:

; 156 : RETAILMSG( 1, (TEXT("*ptr %X\n"), *ptr ));
Now the hard part, why is dereferencing the pointer a problem? In this case, it is because ptr is NULL, but you may need to get out a debugger to find the cause. But at least we now know where the problem is.

In some cases, you may need to start with the Program Counter (PC) insteaad of the Return Address (RA) to find the source of the problem.


-----------------这些都没有试过,是个比较牛的人写得。
楼主如果弄出来的话,把方法贴出来。
gooogleman 2008-10-22
  • 打赏
  • 举报
回复
set WINCECOD=1, build –c, and then open the COD file from obj\%_TGTCPU%\%WINCEDEBUG%. It’ll be named after the C or CPP file – in this case devpnp.cod. The function name will appear several times in the COD file, but in only one case will the function name be followed by the word “PROC,” and this is the beginning of the assembly code for that function. Here’s a sample that’s munged a little from reality.

_I_AdvertiseDeviceInterface PROC NEAR ; COMDAT

; 348 : {

001e8 55 push ebp
001e9 8b ec mov ebp, esp
001eb 81 ec 14 02 00
00 sub esp, 532 ; 00000214H
001f1 a1 00 00 00 00 mov eax, DWORD PTR ___cke
001f6 53 push ebx
001f7 56 push esi

; 349 : ULONG result = ERROR_SUCCESS;

001f8 33 f6 xor esi, esi

As you can see, the source code and line numbers are included in the COD file next to the assembly code that implements the source. Each assembly instruction is labeled with an address. So the COD file provides the mapping from function offset to source line. Sometimes the assembly for the function is labeled starting with 0, and sometimes not. (I believe it may depend on which compiler is being used – meaning it varies by CPU type.) If not, you have to take the function start label into account. So in this example the function starts at label 0x001E8.

---------------没有生成过,这是我在一个老外博客上看到的。

91program 2008-10-22
  • 打赏
  • 举报
回复
没有生成过

最好:clear and build
gooogleman 2008-10-22
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 lmlmlmnew 的回复:]
驱动的source文件里面加个 WINCECOD=1
把debug里面的文件删了
重新编译驱动,里面就有了吧~
反正我这儿好用~~
[/Quote]

我和楼主犯了错误了,哈哈。
我是编译出的是release,
肯定没有这个东西了。
不知道楼主是否也是编译出的是release
lmlmlmnew 2008-10-22
  • 打赏
  • 举报
回复
驱动的source文件里面加个 WINCECOD=1
把debug里面的文件删了
重新编译驱动,里面就有了吧~
反正我这儿好用~~
gsymichael 2008-10-21
  • 打赏
  • 举报
回复
有没有人生成过啊?

19,502

社区成员

发帖
与我相关
我的任务
社区描述
硬件/嵌入开发 嵌入开发(WinCE)
社区管理员
  • 嵌入开发(WinCE)社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧