（计算机系统结构专业论文）嵌入式系统开发调试环境的设计.pdf

文摘 文摘 嵌入式系统在生活中的应用越来越广泛， 它是计算机系统影响人们生活的最 重要的方面之一。 各种各样的嵌入式硬件， 软件层出不穷。 它和桌面p c 不同( 基 本上是w i n t e l 模式) ， 它的硬件种类繁多和软硬件协同的 特点的导致嵌入式系统 上软件的移植和调试的困难. 为了降低嵌入式系统软件开发的难度， 也为了能方便的对新出现的硬件提供 支持，本文提出了一个在p c 平台上交叉开发嵌入式系统软件的开发平台。首先 探讨了嵌入式系统的特点及软件开发调试的过程和方式。阐明了集成开发环境 ( i d e )的使用能提高软件开发的效率， 也是行业发展的大趋势。 本文阐述了基于e l f 格式目 标文件的嵌入式软件源码级交叉调试技术， 简析 了e l f 格式目 标文件的内容， 讨论了宿主机/ 目 标机开发模式中源码级调试的原 理和方法，以及嵌入式软件源码级交叉调试系统实现的技术要点。分析了一个 i d e 所应该具备的基本功能并提出一个总体设计。 在详细设计部分， 对各个实现 细节进行探讨， 对在实现中遇到的问题提出自己的解决办法， 针对种类繁多的各 类设备，对它们进行抽象，提出了虚拟的调试设备的概念。 最后，提供了一个针对 a r m系列处理器和x s c a l e开发平台的实现，包括各 实现模块当中的重要数据结构和算法。 关键词:嵌入式系统， 断点，单步，交叉编译 集成开发调试环境， i d e ， 开发， 调试， a r m , x s c a l e , 反汇编 ab s t r a c t ab s t r a c t p r o d u c t s c o n t a i n i n g e m b e d d e d s y s t e m a r e m o r e a n d m o r e p e r v a s i v e i n p e o p l e s e v e r y d a y l i f e . c h i p s a n d r e l a t i v e s o f t w a r e a r e w i d e l y u s e d i n c a r s , a p p l i a n c e s , l i f e a s s u r a n c e s y s t e m a n d m o b i l e p h o n e s , e t c . e m b e d d e d s y s t e m i s a n i m p o r t a n t p a r a d i g m t h a t c o m p u t e r c h a n g e s p e o p l e s l i v i n g . t h e r e a r e s o m e d i f f e r e n c e s b e t w e e n e m b e d d e d s y s t e m a n d p e r s o n a l c o m p u t e r ( p c ) .a v a r i e t y o f c p u a r c h i t e c t u r e s a r e a d o p t e d i n e m b e d d e d s y s t e m w h i l e t h e r e i s n e a r l y o n l y i a 3 2 c o m p a t i b l e c p u u s e d i n p c . t h e d i v e r s i t y o f e m b e d d e d s y s t e m c a u s e s d i f f i c u l t y o f s o f t w a r e d e v e l o p m e n t a n d d e b u g g i n g . i n o r d e r t o a c c e l e r a t e t h e d e v e l o p m e n t o f s o f t w a r e a n d s u p p o r t n e w h a r d w a r e i n e m b e d d e d s y s t e m . i n t h i s t h e s i s , a n i n t e g r a t e d d e v e l o p m e n t e n v i r o n m e n t ( i d e ) t h a t r u n s o n p c w a s d e s i g n e d . i t s a r c h i t e c t u r e d e s i g n e d i n m o d u l e s m a k e s i t e a s y t o b e u p d a t e d t o s u p p o r t n e w k i n d o f c p u a n d c o m p i l e r . i n t h e b e g i n n i n g p a r t s , s o f t w a r e d e v e l o p m e n t a n d d e b u g g i n g o n e m b e d d e d s y s t e m a r e i n t r o d u c e d . u s a g e o f i d e i s t h e t r e n d o f t h e i n d u s t r y . t h e n e x t i s t h e g r o s s d e s i g n o f i d e . i t d i s c u s s e s s e v e r a l e s s e n t i a l p a r t s o f a n i d e . p r o v i d e d . t h e r e a r p a r t s , a n i 叩l e m e n t o n a r m s e r i e s p l a t f o r m s i s a u t h o r d i v e d i n t o s e v e r a l i m p o r t a n t d e t a i l s a n d m a k e o u t h i s o w n s o l u t i o n s . p r e s e n t e d t o h a n d l e a t t h e e n d o f t h e e v e n t u a l l y , a c o n c e p t o f a b s t r a c t d e b u g d e v i c e i s t h e d i f f e r e n c e b e t w e e n h a r d w a r e a r c h i t e c t u r e s . t h e s i s , s o m e s n a p s h o t s a n d i m p o r t a n t d a t a a n d a r i t h m e t i c o f t h e i m p l e m e n t o f i d e t h a t s u p p o r t s a r m s e r i e s o f i n t e l a r e l i s t e d . s t r u c t u r e s a n d x s c a l e k e y w o r d : i d e , e m b e d d e d s y s t e m , s o f t w a r e d e v e l o p m e n t , d e b u g , a r m , x s c a l e , b r e a k p o i n t , s t e p , c r o s s - c o m p i l e r , d i s a s s e m b l e 第一章 前言 第一章 前言 嵌入式系统是一个内置在更大的、 专用的系统中的计算机系统。 它往往起到 一个核心的作用。 和通用计算机系统相似， 一般它也包括中央处理器 ( c p u ) 、内 存和一些输入输出设备。 不同的是它的外设和所在系统息息相关， 是为实现宿主 系统的特定功能而设置的。 嵌入式系统的历史很长， 早期的计算机系统都是为了 特定的应用设计的， 虽 然当时的电子技术不能将它们集成到应用系统中去， 但是这些计算机系统的设计 开发目标与嵌入式系统是一致的. 可是， 嵌入式系统技术的发展却不如通用计算 机系统体系化、 标准化， 进展也小得多。 这主要因为嵌入式系统应用之间千差万 别， 开发难度大， 成本高。 对于嵌入式系统而言， 提高开发效率， 降低成本是促 进其进一步发展的关键。 现在， 嵌入式系统的应用已经普及到生活的每一个角落， 从手表和烤面包机 到无人工厂的自 动化系统甚至核电站的控制系统， 范围极其宽广。 随着人们生活 水平的提高，手机、 p d a( 个人商务助理) 和p c s( 个人通信助理) 等的使用十 分普及。各种不同的应用的要求也差异很大。工业控制系统要求有高的可靠性、 实时性和长期运行的稳定性。 消费电子产品要求小尺寸、 低功耗， 可靠性与稳定 性也有一定要求. 由于各种不同的嵌入式系统之间差异很大，开发难度也相应变大。 工业控制 系统一般规模大， 操作复杂， 要求大规模团队协作开发。 各种手持移动设备之间 功能往往不同， 无论是外观， 用户交互手段， 还是应用软件都存在差异， 软件的 可重用度不高。 手持移动设备需要高效率的开发技术，以 缩短应市时间， 加快产 品更新。 总而言 之， 嵌入式系统是与 应用紧密结 合的 专用计 算机系 统。 不同 的 嵌入式 系统之间差异大，开发难度高，需要高效的开发手段和工具的支持。 第二章 嵌入式系统开发、调试概述 第二章 嵌入式系统开发、调试概述 互 2 . 1 . 嵌入式系统特点 嵌入式系统是由嵌入式处理器、周边的相关设备、嵌入式系统软件和嵌入式 应用软件所组成。嵌入式系统与通用计算机系统相比有许多自 身的特点。 以应用为导向 “ 以应用为导向”是嵌入式系统与通用计算机系统之间最明显的区别。嵌入 式系统一般都有一个特定的应用目的。 所有的相关的硬件软件设计都是围绕 着其应用目的而来。 资源有限 嵌入式系统有一个 “ 量体裁衣” 的特点，在能达成目的的前提下， 硬件资源 尽可能的节省。所以一般来说处理器速度不快， r a m. r o m及 f l a s h都 不大，只有几个特定的外设。嵌入式系统软件需要精心的设计来实现在有限 资源的条件下完成预定的任务。 l2. 3 .软硬件紧密结合 在嵌入式系统中， 硬件操作需要特定软件控制， 软件运行需要特定硬件环境 支持。在嵌入式系统软、 硬件体系结构内部，各层次、 模块之间的祸合度也 要比 通用计算机系统强。 与此构成鲜明对比的是. 通用计算机系统更强调系 统的模块化、标准化、层次化。 实时性要求高 不少的嵌入式系统，诸如医疗， 航空， 工业控制等，要求对外部事件能有实 时的响应。 现在越来越普及的家用智能设备也有一定的实时性要求，比如家 用安保系统，火灾报等系统等。 稳定性要求高 嵌入式系统很多要求能够长周期稳定运行。比如各种工控机，网络设备， 甚 至外太空探测飞船的控制系统， 都是在无人职守的情况下长时间工作， 要求 有极高的稳定性;即是在某些特殊情况下系统不能正常运行， 也要能够及时 的自 动恢复运行。 : 4哎叶 第二章 嵌入式系统开发、调试概述 2 .2 . 嵌入式系统的开发 嵌入式系统应用都是专用的计算机系统， 所以 系统开发包含了 硬件和软件两 个 部分。 在目 前s o c ( s y s t e m o n c h ip ) 越来 越 普及 的 情 况 下， 开 发 可能 还 包 括 专用芯片开发， 甚至整个系统就在一块芯片上。 一般情况下嵌入式系统开发包括 七个步骤: . 需求分析 . 整体设计与软硬件接口 设计 . 硬件设计与实现 . 硬件测试 . 软件设计与实现 . 软件测试 . 整体测试 嵌入式系统软硬件开发通常采用菱形并行模型。 图2 - 1嵌入式系统开发菱形并行模型 以 上开发流程， 第一步是需求分析。 第二步根据系统的性能、 价格以 及当前 可采用的技术等做出系统的软硬件的功能划分以及接口 设计。 第三步可以同时进 行硬件和软件的设计和实现， 过程中可能会产生反馈来修改上一步的软硬件接口 设计。 第四步进行硬件测试， 通过后再进行软件调试。 第五步是整体调试。 最后 第二章 嵌入式系统开发、调试概述 通过验收后产品发布。 菱形并行模型的软硬件开发是平行展开的。 需求分析完成并定义了软硬件接 口以后， 软硬件就可以同时开发。 各部分独立调试稳定之后再集成调试。 这样避 免了软件开发彻底依赖硬件调试的情况， 提高了整个系统的开发效率。 但是， 错 误可能发现得比较晚，最终集成调试遇到错误定位困难。 整个开发过程中， 软件的设计和实现是一个非常复杂和关键的一步。 软件开 发目 前有多种方式和模型，其中用的比较多的有瀑布模型，螺旋模型等。 由于嵌入式系统本身的资源有限， 操作系统和应用程序的开发一般在一个功 能更强的主机平台上完成， 然后将生成的目 标执行代码传到开发平台的可擦写的 r o m或 f l a s h 中。 这有两种情况。 一种是主机平台的处理器类型和开发平台的相同， 只要使用 主机的编译连接程序，目 标执行代码也可以 先在主机上作初步调试; 另外一种是 主机平台和目 标平台处理器及指令集类型不同， 则需要使用交叉编译器， 调试手 段也相应不同， 可以使用主机端的对目标平台的模拟器来进行， 也可以通过一种 连接方式来连接目 标平台来进行调试。 根据目 标平台上是否有操作系统，开发方式也略有不同，如果有操作系统， 则目 标代码可以使用该系统支持的执行文件格式即可; 如果是裸机，目 标代码需 要附加引导和各个设备的初始化代码。 目前随着各种嵌入式系统应用的普及，对开发速度的要求也越来越高;为了 能在短时间内完成应用系统的开发， 各种辅助工具和手段应运而生， 其中最典型 的就是集成开发环境，它集代码编辑、管理、编译和调试于一身。 第二章 嵌入式系统开发、调试概述 2 .3 . 嵌入式系统的调试 2 . 3 . 1 . 嵌入式系统调试的基本原则 海森堡准则 ( h e is e n b e r g p r i n c i p l e ) 海森堡准则要求尽可能少的影响被调试对象。一般来说，调试器为了进行调 试， 会介入被调试对象的运行，比如给对象的一些位置打标记、更换某些位 置的指令、 修改处理器的寄存器的内容、 等等， 就会干扰被调试对象的运行， 进而有可能影响对象的运行结果。 而调试器影响被调试对象的运行结果就可 能导致对象单独运行时产生我们不期望的结果， 这是不能接受的。 所以调试 器应该尽可能少的影响被调试对象。 尽可能真实和全面的反映被调试对象的信息 真实的调试信息是调试人员进行调试判断、除错的基本依据; 全面的调试信 息可以加速调试过程。 l2. 与被调试对象分离 在调试过程中，可能会发生被调试对象崩溃的情况， 如果调试器与其捆绑在 一起， 这个时候一些珍贵的现场信息就丢失了。当然我们可以通过一些其它 手段来重 现它，比 如c o r e d u m p ， 但效率 上要差一些。 提供可靠的上下文 调试上下文的重要性是怎么强调也不过分的。界定一个错误依靠的信息是: 当前值和预期值的差异及这个差异的整个环境即上下文。 没有上下文， 预期 值往往也不能确定，更不要说判断错误了. 调试上下文最基本的是c p u窗口，它包括当前寄存器组的值，p c值，堆栈 指针和程序状态字等。 变量值的跟踪， 全局变量和局部变量的值很多时候是 调试程序是否出 错的基本依据， 在程序运行异常或访问 越界的时 候， 变量的 值可能非常奇怪。 多线程调试的时候调试器需要能够清楚的显示被调试进程 的各个线程，有时多线程程序需要各线程相互配合，能够将各个进程及线程 间的关系呈现出来是尤其重要的。 比 较上层的另外一个信息是源代码级别的 断点、单步和运行等的调试。 3.4. 第二章 嵌入式系统开发、调试概述 式。 j t a g为此制定了边界扫描标准， 只需5 根引脚就可以实现在线仿真的功能。 该标准己 被批准为i e e e - 1 1 4 9 . 1 标准。 它不但能测试各种集成电路芯片， 也能测 试芯片内各类宏单元，还能测试相应的印刷电路板。 a r m的e m b e d d e d - i c e为j t a g调试提供相应的接口，同时， 为了能达到实 时 ( r e a l - t i m e ) 跟踪调试的功能， a r m架构处理器还内 含嵌入式跟踪宏单元， 可 以用来实现实时跟踪调试的功能。 配合以上三种目 标机端调试方式， 再加上主机端的调试软件以及主机与目 标 机的连接方式，就构成了一个完整的调试系统。 2 .4 . 集成开发环境的重要性 由 于对嵌入式应用程序上市时间的要求己 经成为创造竞争优势的一个关键， 所以嵌入式软件供货商们所面临的一个严峻挑战， 就是要用能够显著提高生产力 的工具，以协助他们的软件开发人员。 集成开发环境( i d e ) 产品为软 件开发人员以 最有效率的形式进行产品 开发 提 供了一种无缝的方式。 通过将大部份软件开发中所需的相关工具结合到一个集成 环境中， i d e能明显缩短设计、 实现、 除错、 测试和部署经过优化的应用程序所 需的时间。很明显，i d e是嵌入式软件开发人员工具库中一种无法衡量其价值， 可提高生产力的工具. 早期的嵌入式开发要涉及几个不同的部份， 分别针对一个典型开发周期中的 “ 编码、编译、 执行、 测试和除错” 阶段。 文件编辑器原始而又不直观的， 程序 员需要精通编辑器命令。 程序必须使用出错率很高的命令行接口进行编译、 执行 和测试。 程序的调试则要通过各种不包含图形用户接口的独立调试器进行。 除了 这些局限之外， 嵌入式开发的特性决定了它要面对具有最少开发工具支持的定制 目 标硬件， 这通常会导致开发周期的进一步延长。 随着嵌入式应用程序复杂性的 成长，这种软件开发方法暴露的几种功能缺陷成为影响上市时间的严重瓶颈。 i d e 是 专门 为 提高 开 发 人员的 生 产 力因 而 提高 软 件 开 发 效 率 而产 生的 。 从 一 个针对编辑、 编译、 测试与除错以及图形用户接口 前端的 基本功能集合开始， i d e 始终往提供更有效软件开发能力的方向发展。 今天， i d e占 据了软件开发人员工 作平台的核心地位， 拥有的一些高级特性已 经深入到了 软件开发的所有方面。 今 天的商业i d e产品都包括一些显著的功能。 几乎所有针对嵌入式应用程序的 i d e都支持从主机操作系统到执行嵌入式 目 标操作系统的嵌入式硬件的交叉开发。 既然目 标硬件通常不适合开发工作， 因 第二章 嵌入式系统开发、调试概述 此大部份嵌入式开发工作是使用交叉开发环境完成的。 最流行的主机开发操作系 统是 wi n d o w s . l i n u x 和u n i x o 所有的i d e 都提供了开发过程中要用到的基本开发工具。其中包括文件编辑器、 多语言支持工具、自 动制作工具、 对编译后的二进制程序代码的执行和调试工具 等。 不过， i d e的文件编辑器提供了更高级的功能， 如语法的高亮显示、自 动缩 进和更好可配置性等; 对用于嵌入式开发中的大多数流行语言， 像c , c 十 十 和j a v a 也提供完全的支持， 这是通过高级的交叉编译器实现的， 它能够生成高度最佳化 的程序代码。 基于ma k e f i l e 的自 动编译和执行系统有了显著的改进， 可产生一种 无缝机制用于制作包含上千个文件的大型软件程序。 调试器能够提供源代码级除 错以及应用崩溃后的反向追踪除错。 在i d e中最值得注意的进步 之一是引入了“ 项目 向导” ( p r o j e c t w i z a r d ) ， 它 能够根据开发者的需要制作项目 代码框架。 例如， 一个应用程序开发者需要制作 一个程序. 其中包含多个独立执行的进程， 进程之间通过信号量进行同步。 根据 这个信息，“ 项目向导”就能够制作一个具备上述功能的样例程序，该程序能真 正在目 标操作系统上被编译通过并执行。在许多 i d e中，这个概念也己被扩展 到制作设备驱动程序范例。 透过这种 “ 项目向导” 功能， 甚至不熟悉嵌入式操作 系统a p i 或其驱动程序模型的开发人员也能够很快上手。 嵌入式开发周期中最重要的阶段之一是在目标硬件上制作和执行操作系统 的映像和嵌入式应用程序。 嵌入式应用程序及其操作系统的一些关键需求， 如目 标程序代码的静态规模和内存使用情况能够透过 i d e提供的相应目 标分析工具 来分析。这些 i d e工具也支持通过某种通讯方式，如串 行端口 或以太网络接口 将目 标映像下载到硬件上。 一旦目 标映像被下载， i d e 工具还能连接到目 标硬件 上，以支持对应用程序或正执行的操作系统的实时调试。 另外一个新近加入到i d e中的扩展功能是剖析 ( p r o fi l e )和最佳化工具。这 些工具可实现在基本的开发和调试完成后对软件程序进行完整分析以确定软件 性能的瓶颈，并调节系统的行为甚至在广泛的测试分析中起辅助作用。 此剖析工具使用专门的方法对软件程序的执行进行深入分析。 这对于确定 执 行开销最大的程序代码段或是追踪特殊的程序代码执行路径都是非常有帮助的。 事件追踪工具提供了一个观察整个系统行为的窗口， 它可追踪外部对系统的中断 及其对应用程序执行的影响。 使用这些事件追踪工具能够将整个系统的行为最佳 化到一种没有这些i d e工具情况下很难达到的水平。 将配置管理工具整合在i d e中是对开发环境的一个自 然扩展。 任何涉及到多 个 软 件版 本的 商 业 软 件开 发 都 需 要 适当 的 配 置 管 理， 主 要 用 来 确保 一 个 特 定原 始 文件的各个版本能够在配置库中被维护， 这可帮助确定与不同软件版本相对应的 第二章 嵌入式系统开发、调试概述 特定 文件。 i d e中 的 配置 管理工 具支持 对一组原 始文 件( 一 般称之为 的无缝储存和获取，因而支持多个软件版本的无缝开发。 这些增加的id e功能经事实证明己经大幅提高了软件开发的效率 p r o j e c t ) 第三章 总体设计 第三章 总体设计 一个现代的嵌入式集成开发调试环境至少需要包括以下部分: 用户交互部分，编译器，调试器，嵌入式调试设备。( 如图3 - 1 所示) 图3 - 1集成开发环境总体结构图 用户交互部分包括:代码编辑，项目 代码管理， 代码编译界面，代码调试界 面。 其中代码调试界面又包括:调用栈，断点，反汇编，寄存器组，内存， 变量 和运行控制等。 编译器一般独立设计，根据支持的语言种类和调试及优化等设置编译参数。 可以降低整个调试环境的祸合度。 被调试设备千差万别，为每一种设备设计一种调试器是效率低下的， 甚至是 不可能的。 调试器其实是一个调试协议的实现， 这个协议定义了一个与整个调试 环境其它部分交互的一个接口， 当有新的设备要加进来的时候， 只要遵循调试协 议来实现该设备的调试模块即可。 调试器和被调试设备之间的连接可能有多种不同的类型，比如串行口，并行 口加j t a g接口， 网络适配器接口 等。 不同的类型需要主机和目 标机的相应的驱 动，也需要调试器的相应的实现。 第三章 总体设计 日 k p t s di sassem s七ackr e g s bank code c o m p i l e e x e c u t i o n e n g in e e x p r e s s eval uati on m e m o r y c ode m g m 士 t a r g e t d e b u g i n t e r f a c e varl abl e c o d ee d it p r o c e s s c o n t r o l ; t a r g e t s y m b o l t o , bl e m g n trun control 图3 - 2集成开发环境层次结构图 图3 - 2 层次结构图中共有四层。最内层是被调试的目标，是硬件层。次内层 为调试接口层， 它提供一个通用调试接口， 如果调试通过主机和目 标机通信， 它 还要包括通信实现部分。 次外层是调试核心层， 实现对调试的内 在支持， 包括进 程控制， 进程执行引擎， 表达式运算，符号表管理。最外层是调试界面层， 提供 与用户交互的功能，共有代码编辑、管理、 编译，调用栈，断点，反汇编，寄存 器组，内存，变量跟踪，运行控制. 3 . 1 . 用户交互部分功能设计 一个集成开发调试环境的成功与否， 用户界面的影响非常大。 设计良 好的界 面可以 减少用户的学习时间， 加速开发过程; 而设计不良的界面即使有一个强大 的编译与调试内核，往往也发挥不出它们的威力。 用户界面包括四个部分:代码编辑，代码管理，代码编译和代码调试。 1 .代码编辑 代码编译的基本功能包括，文件的新建、打开、保存和关闭，字符的键入， 文本的复制、 剪切和粘贴， 字符串的查找、 替换等等。 高阶功能可以 包括语法关 键字的高亮显示， 代码按照一定的编程风格进行格式化， 输入的自 动补全， 初步 的语法错误提醒等。 第三章 总体设计 2 .代码管理 代码管理将一个项目的所有代码按照项目 或模块为单位组织起来， 达到便于 查询、修改和删除的目的。它往往将文件按类型来分类管理，比如c和 c + + 源 代码一 般有.c , .c p p , .c x x , .h , .h p p , .h x x , .i n l , .s , m a k e f i l e 等， 这时 管理 可以 把定义类 文 件 ( . h , .h p p , .h x x ) 归为 一类， 实 现类的 文件 ( c p p , .c x x , .i n l , .s ) 归 为一 类。 管理类的文件 ( m a k e f i l e )归为一类。当然这种归类方法不是强制的，根据不同 的策略可以有不同的方法。 3 .代码编译 现代编译器为了减少代码的编译时间、方便代码的管理，支持将一个项目 的 代码放在多个文件当中。 当代码被修改时， 可以不用重新编译整个项目 而只编译 被修改过的代码， 从而大大节省了开发时间。 经典的编译过程是先将各个代码文 件编译成中间临时目 标文件， 再将各个目 标文件链接成最终的输出文件。 大的项 目 往往文件很多， 手动编译一次耗时耗力， 效率低下，目 前主流的编译器都支持 编译脚本， 一个项目， 只要在编译脚本中指定好编译规则， 以及不同文件之间的 依赖关系，编译过程可以自 动完成。 4 .代码调试 代码调试往往是整个开发过程中占用时间最多的步骤。有统计数据表明， 代 码的编写和调试时间之间的比例大约是3 : 7 的关系。所以调试是非常重要的， 调试质量的好坏也往往影响最终产品的质量。 代码调试包括: 调用栈分析， 软件断点和观察点的设置， 机器指令的反汇编， 寄存器组的监视， 内存内容的监视， 全局和局部变量的跟踪， 调试运行的控制等 等。 3 . 2 . 调试核心的设计 调试界面呈现给用户的功能往往需要调试核心的支持， 一个优秀的调试器是 一定要有好的调试核心的支持。 调试核心包括: 被调试进程的 控制， 调试执行引 擎， 表达式的运算和符号表 管理。调试核心的关键部分是它的进程控制和调试执行引擎子模块。 第三章 总体设计 i .被调试进程的控制 创建被调试程序是调试器要做的第一件工作。 这个受目 标平台上有无操作系 统的影响。如果有操作系统，创建进程一般需要操作系统的相应 a p i的支持， 如果没有操作系统， 实际上也就没有进程的概念了， 但还是有运行线索， 也是可 以调试的。 2 .调试执行引擎 调试执行引擎控制被调试程序的执行，比如设置断点，执行机器指令单步， 查看寄存器和内存的内 容， 程序异常的处理。 一些高阶的功能包括源代码级别的 单步，跟踪变量的值等等。 3 .表达式的运算 在支持用户对变量的值的跟踪的时候， 用户有时会需要知道一个由若干变量 组成的表达式的值。 这样便需要计算表达式， 这往往需要调试符号表的支持， 需 要知道各个变量的类型， 地址， 需要访问内存和寄存器。 如果语言支持运算符的 重载， 并且表达式使用到被重载的运算符， 还需要在表达式求值的过程中执行函 数调用。 如果函数调用有副作用， 表达式的运算便会影响整个调试结果了， 这些 是调试器设计要注意的问题，也是程序调试人员需要关注的问题。 4 .符号表管理 通过查询符号表， 可以把调试过程中的无意义的内存地址和值变成直观易懂 的函数名称、变量地址名称和内容，使除错更加容易. 符号表包括:变量名表，函数名表等。 3 . 3 . 底层调试接口 调试接口是把底层硬件的差异抽象出来，给上层模块提供一个无差异的接 口。 各种不同的硬件之间差别很大， 从体系结构到调试方式可能都不相同。 为了 减少开发的工作量， 可以将硬件按照体系结构和调试方式分类， 然后根据类型来 实现调试模块。 第三章 总体设计 调试模块向外提供的接口 应该包括以下基本功能: . 打开和关闭调试设备 . 初始化调试设备 . 调试设备连接方式的配置 . 断点的设置和清除 . 运行控制 ( 运行、停止、单步) . 寄存器的访问 . 存储器的配置与访问 3 .4 . 可移植性、可扩展性和调试接口的标准化 可移植性是指在某一类型机器上开发的软件不用修改或只需极少量的修改 便能在其它种类的计算机上运行。 本集成开发调试环境使用模块化设计， 降 低了 各个组件之间的祸合度，一定程度上提高了整体的可移植性。 可扩展性是指软件能被修改而在其中添加新的功能的容易程度。 可扩展性和 软件自 身的祸合度高度相关， 祸合度高的软件不易被修改， 反之容易修改而加入 新的功能。 调试工具的设计往往要考虑和己 有的产品兼容，目 前嵌入式系统调试接口 主 要有两个标准:g d i ( g e n e r a l d e b u g i n s t r u m e n t i n t e r f a c e , k o n t r o n , s i e m e n s , t a s k i n g , i m e c , s y n d e s i s , s y n o p s y s 等公 司 提出) ， r d i ( r e m o t e d e b u g i n t e r f a c e , a r m公司提出) 。 这两个标准各提出一套调试接口， 其本质上差别不大。 但r d i 主要面向a r m系列处理器，和a r m的体系结构比较相容。它的接口基本上反 映了a r m体系结构硬件上支持的接口。 而g d i 标准综合各个体系结构之长， 它 并不特定为哪个体系结构而设计， 其中比 较少的 看到某个特定的硬件底层功能的 影子。 本调试环境目 前的调试接口 模块的实现与g d i 相兼容， 以后的发展目 标是同 时兼容g d i 和r d i 接口。 下面分别对g d i 和r d i 的接口作一个简单的介绍: 第三章 总体设计 .gdi g d i 是 一 个调 试接口 标准， 它 使 得 遵照o m i ( o p e n m i c ro p ro c e s s o r i n it ia ti v e ) 的 通用调试器 ( u n i v e r s a l d e b u g g e r ) 能 够透明的 访问 被 调试设备。 它与处理 器， 操作系统，网络和被调试设备无关。 在g d i 标准当中，主要有以 下几大类操作: 调试设备初始化和关闭 调试器设置回调函数 出错处理 调试设备建立内存映射 内存访问 寄存器访问 断点的设置和清除 程序执行控制 调试通讯方式的设置 多处理器控制 .rdi r d i 是a r m公司的一个调试控制器和被调试设备间的接口 协议，调试控制 器 通 常 是一 个 调 试器比 如a x d ( a r m d e v e l o p m e n t s u i te 中 的 一 个 调 试工 具) 。 它提供一个被调试设备或一个模拟的调试设备的抽象。 关于g d i 和r d i 接口的具体介绍，可以参照附录一。 第四章 详细设计 第四章 详细设计 4 . 1 . 模块化设计 集成开发环境往往会面对不同的需求，比如: 支持更多种类的语言， 支持不 同的设备， 不同的连接方式， 不同的调试协议， 也有可能要求能够运行在不同的 主机端系统上。 所有的这些需求促使我们把不同的功能放在不同的并且相互独立 的模块当中， 并且以一种可以动态加载的方式来使用。 这样当一种新的功能实现 以后，可以很方便的加入进来，比如:增加对 j a v a语言的支持，只需要添加相 应的编译器和调试信息模块即可。 如果有一种新的设备加入， 只要添加可驱动它 的调试设备模块。 整个的层次结构图可以参照图3 - 2 所示，它在模块实现上我们使用下面这幅 图，可以看的更清楚一些。 调试界面各模块 调试设备模块 图4 - 1 集成开发环境总体模块图 整个调试系统包括: 核心模块， 实现对调试的内在支持， 包括进程控制、 进 程执行引擎、 表达式运算和符号表管理， 它的各项功能的实现需要更底层的调试 相关的模块的支持;调试设备模块，实现对各种不同的调试设备的驱动和支持; 第四章 详细设计 调试信息模块和编译模块相配合，支持核心模块的表达式运算和符号表的生成; 编译模块，实现为不同目的生成不同的编译结果， 如: 输出有没有调试信息， 输 出在裸机还是一定的操作系统上运行等: 代码管理模块， 为用户提供一个方便的 管理方式， 也为编译大的项目 提供支持; 调试界面和代码编辑模块， 和用户交互， 整个软件的功能最终由它体现. 4 . 2 . 核心模块 4 . 2 . 1 . 进程控制 1 .进程初始化 调试器首先要做的第一件工作是，一旦用户指定了要调试的程序， 就要调用 被调试设备上的操作系统或调试代理等的服务完成初始化进程的工作。 在有操作 系统的情况下， 操作系统对于为主机端准备的被调试程序进程， 不管是通过从头 建立一个新的进程， 还是将被调试程序与已经存在的进程相关联， 都需要通过一 系列的专门的支持调试的系统调用来完成。 在仅有调试代理的情况， 也需要代理 程序完成调试设备的一系列的初始化 ( 处理器、 存储器及外设等的初始化， 中断 处理程序的设置，等等) ，调试过程中也需要代理的协作。如果初始化过程出现 异常， 操作系统或代理程序将通知主机调试器; 进程被正常初始化完毕， 调试器 也将获得一个正确的反馈。 2 . 进程终止 引起进程终止的情况可以有很多， 所以进程的终止反而比它的初始化要复杂 一些。 进程可能正常退出: 也可能由一个致命的异常引发退出: 其它的进程也可 能导致被调试进程的终止: 最后调试器还可以强行终止。 所有这些都需要考虑在 内并且做相应的处理. 第四章 详细设计 4 . 2 .2 . 进程执行引琅 1 . 断点 断点， 是程序调试人员安插在运行的进程中的路障， 当程序运行到断点处会 停下来， 接受调试人员对进程的各项状态的检查。 它是调试除错的重要手段。 断 点一般分两种:断点和观察点。断点，也叫软件断点， 需要修改被调试程序， 将 断点处的指令改为断点指令，当程序执行到断点处后， 触发一个异常， 调试器捕 获这个异常来实现中断程序的执行， 它的响应速度一般比观察点慢， 软件断点在 实现上， 可能有一些差异， 但原理类似; 观察点， 也叫硬件断点，由专门的观察 点寄存器支持， 它不需要修改被调试程序， 响应速度快。 观察点根据它对地址还 是数据敏感可分为地址观察点和数据观察点， 数据观察点对跟踪变量值的变化非 常有用。 所有调试器的执行控制 几乎所有的执行控制算法， 在某种程度上， 都与 断点有关。 这些算法经常需要设置特殊的断点， 有时候可能对干用户来说是完全 不可见的。 1 )对断点算法的要求 下面是对于调试器基本断点机制的几点需求， 断点必须能够充分支持执行控 制特性并且提供现代调试器所需要的丰富特性集合: . 用户可以 在源代码级和指令级插入断点 . 高级断点可以映射到某些特殊文本空间去，比如c + + 模板中的断点 . 每一个用户创建的断点能够被独立维护和显示 . 在同一个源代码或文本位置可以 有多个用户设置的断点 . 用户创建的断点可以是临时设置的并且在下一次停止时自 动被清除 . 断点可以附带条件，并且只有当条件为真的时候才生效 . 断点处于活动状态下，调试器必须能够处理相关的副作用，可选择在被 调试程序停止时，是否报告给用户 . 设 置 在未 装入 模块中 的 断 点， 当 模 块 被 装 入时 ， 能 正 确 解 析 . 由调试器创建的内部断点必须对用户透明 . 在多处理器价格中，对于高级断点必须建立处理器间同步机制 2 )断点数据结构 通常对于断点需要有两级表示机制:逻辑的和物理的。 逻辑断点 一通常对应于用户设置的断点，它们是基于源代码或相应表达式的， 也包括一系列的临时断点。 物理断点与可执行机器指令直接相关的，比 如在程序正文中插入断点指令。 第四章 详细设计 所以在断点的实现中需要分别针对逻辑和物理断点设置两个链表。 物理断点往往 更加真实， 程序执行当中遇到了就会触发。 逻辑断点情况很多， 有活动和非活动 之分， 用户有时需要暂时使某些断点无效; 有临时和永久断点， 比如源代码单步 时候的断点就是临时断点， 触发以后即被清除， 而用户显式设置的断点属于永久 断点: 解析和未解析断点， 有的断点设置在未载入的 模块当中， 这个时候它是未 解析的，当相应模块载入后， 该断点才能生效; 条件断点，比如用户可能需要在 某个变量的值符合一定条件才在某个位置停下来。 总之， 逻辑断点是在物理断点 被触发后，进行仲裁后决定是否要发生的断点。 逻辑断点和物理断点之间可能存在多对一的关系，如下图所示: l e d . c 第2 0 行用户断点 o x 9 o b c 处物理断点 l e d . c 第1 9 行用户单步 在2 0 行产生临时断点 图4 - 2逻辑断点和物理断点 用户可能在同一物理地址设置两个完全不同的断点 ( 停止条件不同) 。从逻 辑到 物 理断 点的 映 射关 系 在设 置、 删除 等 操作 时 改 变。 当 物理 断点 被 触 发时， 需 要反过来检验逻辑断点， 判断如何处理当前断点， 如果是用户设置的断点， 则报 告用户， 如果是一个临时断点， 先取消当前断点， 再报告用户单步等操作执行完 毕， 如果是一个条件断点， 假如条件没有满足， 则继续运行， 反之报告用户发生 条件中断。 由于内在的逻辑到物理断点的多对一的映射关系， 物理级别的控制机 制必须能够知道是否所有映射到某一物理断点列表的每一个节点设置计数器来 实现。 当一个逻辑断点被删除， 并从列表中去除的时候， 只有当对其物理断点的 引用计数器变为零的时候才能够将物理断点清除。 3 )断点的设置和激活 基本的断点设置算法如下描述。 同时用户指定的断点 在源代码的编辑器或者 源代码显示窗口中应该有相应显示. 然后算法将把逻辑断点映射到代码空间的某 第四章 详细设计 个物理断点地址上去。 图4 - 3逻辑断点的设置 图4 - 4物理断点的设置 4 )断点的确认与激活 有时候用户虽然设置了断点， 但是并没有真正的物理断点可与之相对应。 这 是由于从用户可见的源代码到实际可操作的可执行代码之间没有一个有效的映 射。 断点也可能在尚未被装入的动态链接库代码中。 或者， 有可能由 于用户修改 了代码， 而编译器尚没有将源代码翻译成可执行的机器指令， 所以连真正的进程 都不存在。 不管是哪一种情况， 用户设置的断点， 逻辑断点， 仍然可能在没有相 应的 物理断点的情况下存在， 并且保持无效状态直到以 后某个时刻。 事实上， 该 断点也可能永远无法成为一个有效的断点， 因为它有可能是设置在不可执行的声 明上。 除非编辑器分析了源代码， 并且编译器建立了一张声明表以描述源代码文 本中每一个可设置断点的有效位置。 一旦进程创建完毕， 或者相应的库文件装入 成功，检查有效性的算法就会最终完成从无效逻辑断点到物理断点的映射。 断点的有效性必须在尽可能早的时候完成。当进程被创建的时候，在没有任 何指令执行之前， 调试器有着足够的时间处理所有的无效断点， 并且进行必要的 物理断点插入工作。 但是对于运行过程中， 后装入的库就有些困难。 幸好大多数 现代操作系统在完成装载或者卸载一个模块时，都会提供一个调试事件或者通 知。 这个通知会导致库文件装载完毕后， 在库中没有任何指令被执行前， 被调试 第四章 详细设计 程序的停止执行。 这样调试器就有机会能够及时的检查出库中任何可能遇到的 断 点， 并且将它们都设置为有效。 在我们实现的调试器中设置断点有效属性的代码 被安排在b r e a k p o i n t 中， 每次当 有 执行模块被装 入时， 都会遍历未 被解析的 断点 以确定是否有断点在该库当中。 s )临时断点 断点有很多属性， 其中一个就是该断点是临时还是永久的。 临时断点一般用 来实现从用户角度看来似乎与断点无关的功能， 比如用户执行源代码的运行到某 个函数停止， 运行到当前光标处等的功能。 这时候需要调试器先进行裁决， 判断 用户需要程序停止的位置，再在该处设置一个临时断点，然后让程序全速运行。 某个临时断点被触发后， 所有的临时断点都将被清除， 然后向用户报告运行到当 前光标处的操作完毕。 临时断点带来的便利是操作简便， 不用手工再设置和