VS 2005使用map文件查找程序崩溃原因(转载,很好)

本文介绍了一种利用map和cod文件定位程序崩溃原因的方法。通过配置Visual C++ 2005生成这些文件,可以在多线程环境下准确找到导致崩溃的具体代码行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


一般程序崩溃可以通过debug,找到程序在那一行代码崩溃了,最近编一个多线程的程序,都不知道在那发生错误,多线程并发,又不好单行调试,终于找到一个比较好的方法来找原因,通过生成map文件,由于2005取消map文件生成行号信息(vc6.0下是可以生成行号信息的,不知道microsoft怎么想的,在2005上取消了),只能定位在那个函数发生崩溃。这里可以通过生成cod文件,即机器码这一文件,具体定位在那一行崩溃。

首先配置vc2005生成map文件和cod文件:
(1).map文件:property->Configuration Properties->Linker->Debugging 中的Generate Map File选择Yes(/MAP);

(2).cod文件:property->Configuration Properties->C/C++->output Files中Assembler OutPut中选择Assembly,Maching Code and Source(/FAcs),生成机器,源代码。

上面所说的 property 是“项目”菜单下的 property,而非“工具”菜单下的 property。(转者注)

简单例子:


  
void errorFun(int * p)  
{  
 *p=1;  
}  
  
int _tmain(int argc, _TCHAR* argv[])  
{  
 int * p=NULL;  
 errorFun(p);  
 return 0;  
}  

在errorFun中函数中,*p=1这一行出错,由于p没有申请空间,运行时出错,弹出
Unhandled exception at 0x004113b1 in testError.exe: 0xC0000005: Access violation writing location 0x00000000.
在0x004113b1程序发生崩溃。

具体步骤:
(1)debug文件下打开map文件,定位崩溃函数.

map文件开头是一些链接信息,然后我们要找函数和实始地址信息。地址是函始的开始地址

Address       Publics by Value       Rva+Base    Lib:Object

0000:00000000    ___safe_se_handler_count   00000000    <absolute>
0000:00000000    ___safe_se_handler_table   00000000    <absolute>
0000:00000000    ___ImageBase         00400000    <linker-defined>
0001:00000000    __enc$textbss$begin      00401000     <linker-defined>
0001:00010000    __enc$textbss$end       00411000     <linker-defined>
0002:00000390    ?errorFun@@YAXPAH@Z    00411390 f    testError.obj
0002:000003d0    _wmain            004113d0 f    testError.obj
0002:00000430    __RTC_InitBase        00411430 f   MSVCRTD:init.obj
0002:00000470    __RTC_Shutdown        00411470 f   MSVCRTD:init.obj
0002:00000490    __RTC_CheckEsp        00411490 f   MSVCRTD:stack.obj
0002:000004c0    @_RTC_CheckStackVars@8    004114c0 f   MSVCRTD:stack.obj
0002:00000540    @_RTC_AllocaHelper@12     00411540 f    MSVCRTD:stack.obj

....

程序崩溃地址0x004113b1,我们找到第一个比这个地址大的004113d0,前一个是00411390,地址是函数的开始地址,所以发生的崩溃的的函数是errorFun,这个函数的初始地址00411390.

(2)找出具体崩溃行号.

由(2)可知,发生错误函数是errorFun,在testError.obj,打开testError.cod文件,找到errorFun函数生成的机器码.

?errorFun@@YAXPAH@Z PROC ; errorFun, COMDAT

; 7 : {

00000 55 push ebp
00001 8b ec mov ebp, esp
00003 81 ec c0 00 00
00 sub esp, 192 ; 000000c0H
00009 53 push ebx
0000a 56 push esi
0000b 57 push edi
0000c 8d bd 40 ff ff
ff lea edi, DWORD PTR [ebp-192]
00012 b9 30 00 00 00 mov ecx, 48 ; 00000030H
00017 b8 cc cc cc cc mov eax, -858993460 ; ccccccccH
0001c f3 ab rep stosd

; 8 : *p=1;

0001e 8b 45 08 mov eax, DWORD PTR _p$[ebp]
00021 c7 00 01 00 00
00 mov DWORD PTR [eax], 1

; 9 : }

00027 5f pop edi
00028 5e pop esi
00029 5b pop ebx
0002a 8b e5 mov esp, ebp
0002c 5d pop ebp
0002d c3 ret 0
(说明: 7,8,9是表示在源代码的行号。
00000 55 push ebp,000000是相对偏移地地,55是机器码号,push ebp,000000是汇编码。)

通过(2)我们计算相对偏移地址,即崩溃地址-函数起始地址,0x004113b1-0x00411390=0x21(16进制的计数)。找到0x21这一行对应的机器码是 00021 c7 00 01 00 00,向上看它是由第8行*p=1;生成的汇编码,由此可见是这一行程序发生崩溃。


结束语:当然这只是一个简单的例子,实际上一运行便知道是这一行出错,但是对于一个比较大的工程,特别是在多线程并发情况下,要找出那一行出错比较困难,便可以使用map和cod文件找到程序崩溃原因。


<think>好的,用户想了解如何解读IAR生成的.map文件。首先,我需要回忆一下.map文件的作用和结构。map文件通常由编译器生成,主要用于链接阶段,记录代码和数据的内存分配情况。这在嵌入式开发中尤为重要,因为资源有限,需要精确控制内存使用。 接下来,我应该考虑IAR环境下的.map文件有哪些具体内容。根据用户提供的引用,map文件包含IAR版本、日期、输出文件路径等信息,还可能涉及模块、段的大小和地址。可能需要分模块、段、符号表等部分来解析。 用户可能对如何找到这些信息有疑问,比如如何开启生成.map文件的选项,但根据引用[2],用户已经知道如何设置IAR生成map文件,所以可以跳过这部分,直接进入解析内容。 需要详细说明每个部分的含义。例如,模块信息可能列出每个源文件或库占用的空间,段信息包括代码段、数据段的起始地址和大小,符号表则显示函数和变量的具体地址。此外,堆栈信息也很重要,尤其是在资源受限的系统中。 用户可能还想知道如何利用这些信息优化程序,比如查找内存使用过大的模块,或者确认变量是否正确地分配到预期地址。需要注意提醒用户关注总内存使用量是否超出硬件限制,以及是否存在内存碎片等问题。 最后,生成相关问题时要围绕.map文件的应用场景、优化方法、错误排查等,帮助用户进一步深入学习。例如,如何通过map文件分析内存溢出,或者如何调整链接脚本来优化内存布局。</think>### IAR .map 文件解读指南 #### 一、文件基础信息 .map 文件开头包含编译环境元数据: - **IAR 编译器版本**:例如 `IAR ANSI C/C++ Compiler V9.30.1` - **生成日期与时间**:如 `2023-10-01T14:30:45` - **输出文件路径**:指向生成的 `.out` 或 `.hex` 文件[^1] - **链接配置文件**:显示使用的 `.icf` 文件路径,例如 `"project.icf"`[^2] #### 二、关键结构解析 ##### 1. 模块占用统计(MODULE SUMMARY) 表格形式列出所有参与链接的模块: ``` Module Code (bytes) RO Data (bytes) RW Data (bytes) main.c 1024 256 128 libmath.a 2048 512 0 ``` - **Code**: 代码段大小 - **RO Data**: 只读数据(如常量字符串) - **RW Data**: 初始化变量占用空间 ##### 2. 内存区域划分(MEMORY CONFIGURATION) 展示链接脚本定义的内存区域: ``` Name Origin Length Attributes FLASH 0x08000000 256K xr RAM 0x20000000 64K rw ``` - **Origin**: 内存起始地址 - **Length**: 分区容量 - **Attributes**: 访问权限(x=可执行,r=可读,w=可写) ##### 3. 段分布详情(SECTION ALLOCATION MAP) 描述各段在内存中的具体分布: ``` FLASH: 0x08000000 0x400 .intvec // 中断向量表 0x08000400 0x800 .text // 代码段 RAM: 0x20000000 0x100 .data // 初始化变量 0x20000100 0x200 .bss // 未初始化变量 ``` ##### 4. 符号地址表(SYMBOL TABLE) 包含全局/静态符号的绝对地址: ``` main 0x08000401 Code GLOBAL // 主函数入口 g_sensor_data 0x20000020 Data STATIC // 全局变量 ``` #### 三、实战分析技巧 1. **内存超限检测**:对比各区域 `Length` 与实际使用量 2. **代码膨胀定位**:通过模块统计表识别占用异常的库文件 3. **对齐问题排查**:检查地址尾数是否遵循4字节对齐(ARM架构要求) 4. **中断向量验证**:确认 `.intvec` 段起始地址与芯片手册一致 #### 四、典型应用场景 - 优化FLASH/RAM使用量时,识别可精简的模块 - 调试HardFault时,通过符号表定位崩溃地址 - 验证关键数据结构的物理地址是否符合硬件要求 - 分析多模块系统中的内存占比分布 $$ \text{剩余空间} = \text{区域长度} - (\text{末地址} - \text{首地址}) $$
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值