arm linux问题

这种功能用qt是没有问题的 功能也不是特别复杂 在学习qt方面 建议如下：

首先手上应该有一本比较详细一点的qt方面的书 而且最开始的时候应该从一些简单的例程开始

慢慢等你花上几天熟悉了套路之后 你就可以开始尝试着一下你的项目了 首先是从你需要的对象类开始 一点一点开始尝试 等你项目快完成的时候 qt也就熟悉了 刚开始学都会有些困难的 祝你顺利！

Trustzone可以追溯到十多年前，ARMv7公布的时候就有了，可惜一直没有什么实际应用。直到近几年开始，才真正的有厂商开始把这个方案大规模用于芯片里。目前看到的主要有四个应用领域：\x0d\x0a第一是无人机芯片，大疆已经走在了最前面，第二名连影子都没看见。无人机上几大应用，图像传输，图像处理，识别，飞控，存储，每一块都有安全的诉求。利用Trustzone可以做到，在芯片里流动的数据，每一步都在安全系统的控制之下，哪怕飞机被人抢去，都需要极大的代价才能拿到闪存以及内存里面的数据。如果以后上安卓或者其他 *** 作系统，哪怕软件系统被黑客攻破，数据和控制还是安全的。最后，如果国家或者行业出台政策，要求实施禁飞区，那么哪怕无人机的主人自己去修改闪存和软件，都可以被强制接管。这些功能必须在芯片设计阶段就考虑到，大疆在这方面的眼光确实比别人长远。\x0d\x0a第二是DRM，数字版权管理，也就是内容保护。如果国内用户要在手机上看最新好莱坞大片，那么播放设备必须经过一个认证，这个认证可以用trustzone来实现。国内已经在积极的推动这个事情，估计再过一段时间就可以实现了。当然，这是一把双刃剑，肯定也有用户反而不愿买支持DRM的设备，而去看盗版。用了Trustzone本身并不限制盗版，只不过多了一个看好莱坞大片的渠道。\x0d\x0a第三是支付。把Trustzone用于支付支付在技术上没有困难，对芯片性能要求也不高，难的是把各个利益方摆平。银行和运营商想把支付控制权握在自己手里，所以会去大力推广NFC，会去和苹果合作。而手机支付软件厂商，比如支付宝和微信，想通过和手机芯片和硬件厂商，把所有功能都自己的平台上实现。目前的支付大多数还是基于软件和远端密钥验证。如果有人把手机破解，那还是可以读取到支付图层的密码的。而trustzone做的，就是硬件上杜绝这类情况。\x0d\x0a第四是物联网。物联网的安全有好几种做法，可以把安全检测放在服务器端或者末端芯片上。末端通常是一个MCU加上传感器和互联模块，面积较小。用硬件trustzone实现的话，加解密和密钥管理等功能会需要额外内模块，可能比MCU本身都大，成本太高。但如果是附加值高的芯片就没什么问题。\x0d\x0a让我们从技术层面来定义Trustzone到底能做什么：\x0d\x0a1、防止 *** 作系统被攻破后关键数据泄密，关键数据存放在特定内存区域，而那块区域，只有安全 *** 作系统才有可能读到。\x0d\x0a2、防止通过JTAG等调试接口读到寄存器，缓存，内存或者闪存数据。\x0d\x0a3、从芯片制造开始，最初的密钥可以用芯片熔丝实现，往后启动的每一步都需要最高特权级和密钥验证，建立信任链，杜绝软件被替换或者被恶意读取。\x0d\x0a4、防止边带攻击，比如量取内存颗粒的信号猜测数据，制造故障让检验模块停止工作，替换外围器件，输入特定数据确定电磁信号特征，打开芯片直接量内部信号线等。\x0d\x0a\x0d\x0a上一个典型的ARM SoC内部结构，在这个结构里，Trustzone做的事情是保护数据在芯片内部的安全，不允许非授权的访问，哪怕这个访问来自CPU。初看有些复杂，不过我们可以拆开慢慢分析。从硬件角度开始比软件更清楚些，说不定哪天过认证的时候需要答辩，从头到尾解释系统安全设计。\x0d\x0a首先，按照Trustzone的划分，一个芯片内被划分为安全世界和非安全世界。上图中，中间黑色的部分是总线，总线上面是主设备，下面是从设备（主设备中的缓存是例外，这个以后说）。读写请求总是从主设备发往从设备的。\x0d\x0a作为从设备，区分它是不是属于安全世界相对简单。如果一个从设备不存在成块的空间映射，比如I2C或者PWM，那么我只要在总线访问它的时候，额外的加入一个管脚(取名为PROT)，就可以告诉它本次访问是不是来自安全世界。如果从设备本身是完全属于被保护的安全世界，不接受非安全的访问，那么只要简单的拒绝，返回错误或者无意义数据即可。同样，如果从设备本身处于非安全世界，那么对于安全和非安全访问，都可以返回正确数据。还有，从设备所处于的世界，是可以动态配置的，且动态配置本身需要处在安全世界，这个以后讨论。\x0d\x0a对于块设备，包括闪存，sram和内存等，它们的某些地址块需要处于安全世界，其他的处于非安全世界。为了实现这一点，就需要在它们前面插入一个检验模块（例如图中左方，DDR上面的TZC400），来判断某个地址是不是能被访问。当地址被送到这个检验模块，模块会结合PROT管脚去查表，看看本次访问是不是被允许，然后做相应措施。表本身和之前的动态配置一样，必须是在安全世界里面配置的。\x0d\x0a至此，从设备就分析完了，是不是感觉特别简单？还有些细节，在把主设备也讲完后，我们会从系统角度来关注。\x0d\x0a对于一般主设备，不考虑自带的缓存时，其实和从设备也差不多，也分为安全和非安全，可以在安全世界动态配置。配置完成后，这些主设备会按照自己所处的世界，驱动PROT管脚和地址来访问从设备，得到相应返回。不过这里的一般主设备不包括中断控制器，系统MMU，调试模块和处理器，接下来对这些例外模块进行具体分析。\x0d\x0a\x0d\x0a首先是处理器。\x0d\x0a在上图情况，接了CCI总线后，处理器接在缓存一致性端口ACE上（不明白的请参考以前的文章），它的缓存是可以被别人访问的，并且这个访问，是从主设备到主设备（当然，在处理器内部是从端口），不会经过总线送到内存，也不会经过检验模块TZC400。这时就有个漏洞，通过 *** 纵一个非安全世界的模块，比如上图的橙色主设备，假装去读一个被安全世界保护的内存地址。这个地址本来存在于内存，被TZC400保护，可是由于总线的监听功能，读请求有可能被发往处理器缓存，从而绕过保护。\x0d\x0a为了防止这种情况，处理器在所有的页表和缓存都做了特殊设计，加了一个标志位，标志本缓存行是否属于安全世界。如果别的非安全世界主设备来监听安全世界缓存行，由于安全位不同，处理器会认为这是两个不同地址，哪怕它们的地址一致，返回缓存未命中。这样，就不会把数据泄漏。\x0d\x0a有人会问，这个标志位来源于页表，改了页表中的这一位不就可以访问了？其实不行。因为安全世界页表位于被保护的内存区域或者缓存，就算破解了 *** 作系统也无法访问。\x0d\x0a又有人会说，那改了非安全世界的页表中安全位，并伪造一个安全世界的地址，岂不是可以让CPU模拟出一个访问安全世界的传输，送到总线和TZC400？TZC400或者对端缓存一看地址和PROT管脚都是符合要求的，应该就会返回保密数据吧？想法是不错，可是当CPU位于非安全世界时，它会忽略页表中的安全位，所以不可能发出PROT为安全的传输。所以，我们可以对这点放心。\x0d\x0a以上是别的主设备访问处理器，那如果处理器本身处于非安全世界，有没有可能访问其他主设备的安全缓存？当然有。所以不要把其他主设备接到ACE端口，以免被监听，一般主设备是不会做缓存上的安全与非安全区分的。接到ACE-Lite接口无所谓，反正设计上就无法被读取缓存数据。\x0d\x0a除此之外，还存在一个例外，就是GPU。在最新的ARM G71图形处理器上，是支持双向硬件一致性的。也就是说，GPU也可以被监听缓存的。为了简化设计，图形处理器被设成永远处于非安全世界，CPU尽管读，不在乎，它使用另外一种机制来保护数据，以后介绍。\x0d\x0a对处理器缓存熟悉的人可能会想到用跨缓存行的非安全变量来访问被保护的数据。没用的，处理器设计者早就想到这点，要不就是非对齐访问异常（包含exclusive access的时候），要不就不会给你数据，具体到每个处理器有所不同。\x0d\x0a还有一个漏洞没堵上，那就是缓存维护，TLB和分支预测 *** 作。ACE端口包含了DVM *** 作来维护它们，安全性如何保障？同样的，地址中也有安全和非安全位。不过话说回来，DVM *** 作无非就是无效化某些缓存，分支预测和TLB项，不存在安全数据被读取，TLB被篡改的情况。\x0d\x0a到这里可能你会觉得有点晕，不少漏洞需要堵。我们可以回顾一下，需要记住的是各种缓存 *** 作，通过安全标志位保护，避免漏洞。对比处理器设计者所要考虑的情况，这点漏洞不值一提。\x0d\x0a杜绝了缓存漏洞后，还有别的隐患，比如仿真器。调试模块可以被用来访问各个从设备，也可以访问和影响处理器内部资源。从设备侧的防护很容易，把调试模块当成一般的主设备处理就行。处理器内部的寄存器，缓存等资源，需要处理器从设计开始，就要为所有资源定义安全级别。被保护的资源对于来自调试模块的未授权访问会被禁止。只有通过安全启动链，安全世界的软件才能打开寄存器SDER，从而允许外部仿真器影响被保护的安全世界资源和处理器运行状态，访问被保护的资源。\x0d\x0a那处理器内部的资源是怎么划分的？以ARMv8举例，如下图：\x0d\x0a\x0d\x0a这幅图相信很多人都看到过。ARMv8的处理器被分成四个特权等级，通常EL0跑用户态程序，EL1内核，EL2虚拟机。EL0-1分为安全与非安全，EL3只有安全世界，EL2不区分，两个世界的切换必须经过EL3。我们谈到的处理器内部资源，包括寄存器，缓存，异常，MMU，很多都会分组，组之间看不到或者低级不可访问高级，从而保证安全。没有分组的，比如通用寄存器，就需要软件来维护，防止非安全世界的看到安全世界的数据。\x0d\x0a引起安全切换的会有几种可能：中断和SMC指令。中断分为如下几种情况：\x0d\x0a\x0d\x0a非安全世界下，在EL1或者EL0，当一个非安全中断来临，那么系统没必要切换安全状态，作为一般中断处理，切到EL1即可。\x0d\x0a非安全世界下，在EL1或者EL0，当一个安全中断来临，那么系统必须先切到EL3，不然就没法做安全世界切换。\x0d\x0a安全世界下，在EL1或者EL0，当一个安全中断来临，没必要做安全世界切换，作为一般中断处理，切到EL1即可。\x0d\x0a安全世界下，在EL1或者EL0，当一个非安全中断来临，那么系统必须先切到EL3，不然就没法做安全世界切换。\x0d\x0a当跳到EL3的Secure Monitor程序处理上下文切换时，IRQ/FIQ中断屏蔽位不起作用，哪怕打开了也不会触发，直到Secure Monitor处理完，向下跳到相应的安全世界EL1时，才会让原来的中断屏蔽恢复，从而触发中断。此时处理中断的是安全世界的中断程序，处于被保护的内存区域，杜绝非安全世界的程序篡改。\x0d\x0a那怎样触发安全与非安全中断呢？这在中断控制器里有定义，早年的定义中只有FIQ可以作为安全中断，后期的可配置，并且，相应的安全世界配置寄存器只有在处理器的安全世界中才可以访问。\x0d\x0aSMC指令和中断触发类似，只不过软件就可以触发，切换到Secure Monitor。这里，非安全软件可以提出触发请求，在通用寄存器填入参数，却无法控制安全世界的处理程序做什么，也依然看不到被保护内存数据。所以防止数据泄密的任务就靠安全 *** 作系统了。\x0d\x0a至此，安全启动后的基本硬件防护已经完成，但如果你以为这就是Trustzone，那就错了，精彩的在后面。\x0d\x0a我们可以把Trustzone放到实际应用里面看看是不是可行。以DRM举例，如下图：\x0d\x0a\x0d\x0a在播放授权 视频的时候，视频流来自网络或者闪存，它们不需要在安全世界，因为数据本身就是加密过的。然后被解密并放到被保护内存，等待解码。上图中，密码保护和解密是通过安全硬件模块Crypto来完成的，这个我们以后再分析，先处理解密完成后的视频流。此时有两种方案：\x0d\x0a第一中，非常自然的，可以把所有的过程在安全世界完成，那么图形处理器，视频处理器和显示模块必须都工作在安全世界，能访问安全世界的数据，才能完成工作。可这样就带来一个问题，那就是驱动。我们知道，图形处理器的驱动是非常复杂的，并且手机上只存在Linux和windows下的图形驱动，和OpenGL ES/DirectX配合。\x0d\x0a而安全世界的 *** 作系统（TEE，Trusted Execution Environment）是完全不兼容的安全系统，甚至有的都不支持SMP， 完全不存在可能性把图形驱动移植上去，也没有任何意义。这样的话，就只能把图形处理器从流程中挖掉，只留下相对简单也不需要生态的视频和显示模块的驱动，工作在安全世界，而GPU的输出送到显示模块，由显示模块进行混合。\x0d\x0a这是一种可行的方案，也确实有公司这么做。但是从长远看，图形处理器总是会参与到这个过程的，别的不说，只说VR和AR流行以后，要是虚拟个显示屏出来，上面播放视频，然后放在一个虚拟出的房间，那他们之间肯定是要进行互动的，此时显示模块就需要把视频图层送回GPU进行运算。如果GPU不在安全世界，那就会造成泄密。\x0d\x0a为了解决上述问题，有了第二种解决方案，称作TZMP1（Trustzone Media Protection 1），引入了保护世界的概念。\x0d\x0a保护世界工作于非安全世界，这样才能兼容图形驱动。那安全怎么办？它需要添加四根管脚NSAID，类似于安全世界的PROT信号，只不过做了更细的划分，使得GPU/视频/显示模块要访问被保护内存时，预先定义好了权限。而这个权限的设置，也是通过前文的TZC400来实现的，在安全启动链中就完成。CPU的权限通常是0，也就是最低。而显示控制器权限是只读。\x0d\x0a这样一来，我们之前的老问题，恶意缓存监听，又回来了。在新的A73和G71加CCI500/550总线系统里，可以支持双向硬件一致性。这意味着GPU也能被监听。这下大家都在非安全世界，缓存里的安全位不起作用，怎么解决？这需要总线的配合。\x0d\x0aARM的总线CCI500/550，有一个保护模式，打开后，不光支持上文的NSAID管脚，还可以在监听的时候，把监听传输替换成缓存行无效化命令，直接让目标把相应缓存行无效化。这样一来，数据还是需要从内存读取，保证安全。并且这个过程对软件透明，无需做任何改动。\x0d\x0a可是此时，辛辛苦苦设计的硬件一致性就完全起不到加速作用了，性能受到影响。好在运行OpenGL ES的时候，GPU是不会发出共享传输的，CPU也不会没事去监听GPU的数据。而下一代的图形接口Vulkan，会开始使用GPU双向一致性，那时候会有影响。还有一点不利的是，如果同时运行OpenCL和DRM，OpenCL也用不上双向硬件一致性，必须重启系统切换到非保护模式才行。\x0d\x0a还有，在实际使用中，现有的TZC400作为内存保护模块，有几个致命的缺陷。\x0d\x0a第一，它的配置只能在启动时完成，无法动态改变，也就是说，一旦某块内存给了安全世界，就无法再被非安全世界的 *** 作系统使用，哪怕它是空闲的。在4K视频播放时，需要分配几百兆内存，还不止一块。\x0d\x0a如果一直被占着，这对于4GB内存手机来说是个沉重的负担。怎么解决？只能改成动态配置。此时，如果内存不够了，非安全 *** 作系统提请求给安全系统，让它把暂时不用的物理内存设到非保护内存区，并定个时间收回。不过这样一来内存分配机制就复杂了，说不定还得改内核，很危险。\x0d\x0a如果忽视这点，继续往下走，还会遇到第二个问题。TZC400和它的改进版最多只能支持最小颗粒度为2MB的内存块管理。为什么不弄细些呢？很简单，如果设成4KB，和系统页大小一致，那么4GB的物理内存就需要一百万条目来管理。如果做成片上内存，比二级缓存还大，不现实。\x0d\x0a而做内存映射，就和MMU一样了，经过CPU的MMU后，数据访问还要再穿越一次MMU，延迟显然大。此外，这一层的MMU无法利用一二级缓存放页表，效率极低。如果继续保持2MB的颗粒，那么在分配内存的时候，很快就会因为块太大而用完。就算使用了上一节的方法，问题也没法很好解决。这就是TZMP2V1。\x0d\x0a在这种情况下，第三种基于虚拟机的方案就出现了。不过这个方案基本上推翻了Trustzone最初的设计意图，我们来看下图：\x0d\x0a\x0d\x0a在这里，作为内存保护的TZC400完全移除，而系统MMU加了进来。内存保护怎么做？靠物理地址重映射。先看处理器。在启动链中，从EL3向EL2跳的过程时，就定义好保护内存，并且EL2,也就是虚拟机的页表存放于保护内存，EL1的安全页也同样放在保护内存。\x0d\x0a这样，当处理器进入到EL1，哪怕通过篡改EL1非安全页表的安全位，也最终会被映射到它所不能访问的安全内存，从而起到保护作用。同样的，给处于非安全世界的控制器也加上系统MMU，让设备虚拟化，同样可以控制安全。这就是TZMP2V2。有了系统MMU，页表可以做成4KB大小了，也不用担心CPU那里穿越两次MMU。这时候，也不用担心恶意监听缓存，因为所有穿过二级MMU的访问里，安全位都是经过检验的的。\x0d\x0a但是，不看别的，光是为设备加入这些系统MMU，就会增加很多面积。还有，光加MMU不够，还要加入系统的三级甚至四级缓存，才能让MMU效率更高，不然延迟太大。当然，如果设备使用的页表并不很多，可以对MMU简化，比如增大最小颗粒度，减少映射范围，直接使用片内内存。这需要系统设计者来做均衡。对于GPU来说，要支持双向一致性，还得考虑让监听传输通过MMU，不然功能就出问题了。\x0d\x0a如果使用了TZMP2V2，那么虚拟化就变成了一个切实需求。然后会发现，ARM的中断和设备的虚拟化还很不完善。接下来我从硬件角度解释下虚拟化。\x0d\x0a说到虚拟化，先要解释系统MMU。\x0d\x0a\x0d\x0a如上图所示，系统MMU其实很简单，就是个二层地址转换。第一层，虚地址到实地址，第二层，实地址到物理地址。请注意，没有第二层转换时，实地址等同于物理地址。这个模块既可以两层都打开，也可以只开一层，看情况而定。\x0d\x0a\x0d\x0a上图比较清楚的显示了一层映射的过程。其中，设备发出的虚地址请求，会先经过TLB，它里面存了以前访问过的页表项，如果有，就直接返回，没有就往下走到第二步table walk。\x0d\x0a第二步里，MMU会按照预设的多级基址寄存器，一级级访问到最终页表。如果MMU位于CPU内，那table walk过程中每次访问的基址和表项，都可以存放于缓存中，大大提高效率。如果在设备上，只有内建的TLB表项，后面没有缓存，那未命中TLB的都是访问DDR，效率自然下降。\x0d\x0a所以CPU和GPU等经常访存的设备，都是自带第一层MMU和缓存。而对于没有内部MMU，切换页表又不是很频繁的设备，比如DMA控制器，可以在下面挂第一层MMU，此时驱动就简单了，直接把应用程序看到的虚地址给DMA的寄存器就行，MMU会自己按照基地址去查找相应页表并翻译，把实地址送到总线。不然，驱动还要自己查找实地址再写入寄存器。\x0d\x0a我们前面说过，在TZMP1和TZMP2v1中，内存保护是靠TZC400来完成的。而到了TZMP2v2，取消了TZC400，这时靠虚拟化的二层地址映射。\x0d\x0a二层映射的过程和一层映射基本一样，不再详述，但是性能问题会被放大。假设在一层中，经过四级基址查到最终页，而在二层中，这每一级的基址查找，又会引入新的四级基址访问。所以至少要经过4x4+4=20次访存，才能确定物理地址。如果没有缓存的帮助，效率会非常低。\x0d\x0a其他可行的办法是减少基址级数，比如linux只用了三级页表，但即使如此，也需要3x3+3=12次查找。在包含缓存的ARM CPU上，虚拟机的效率可以做到80%以上。而二层MMU应用于设备实现设备虚拟化的时候，就需要小心设计了。\x0d\x0a有了系统MMU，我们就有了全芯片虚拟化的基础。那在对系统性能和成本做完平衡，采取合适的系统MMU设计之后，是不是就可以实现虚拟化，并且靠虚拟化实现安全了？没那么容易，还有其它问题需要考虑。\x0d\x0a虚拟化脱胎于仿真器，就是在一个平台上模拟出另一个平台。在指令集相同的时候，没有必要翻译每一条指令，可以让指令直接被硬件执行，这样指令的效率算是得到了解决。当然，对于某些特殊指令和寄存器访问，还是需要hypervisor处理的。接着第二个问题，访存。\x0d\x0a我们前面解释过，对CPU来说，高效的虚拟化访存，就是让指令高效的经过两层翻译，而不是每次访存都需要触发虚拟机EL2的异常，切到Hypervisor，再得到最终物理地址。这一点在没有缺页异常的时候，ARM的虚拟化也已经做到了，而有缺页异常时还是需要Hypervisor处理。再接着是设备访存虚拟化，有了系统MMU，也可以高效做到。再就是处理器和设备中断虚拟化。\x0d\x0a最后，设备的虚拟化需要管理，那设备本身需要支持虚拟设备号和虚拟中断号。更多内容请期待。

在基于ARM的嵌入式系统开发中，常常用到交叉编译的GCC工具链有两种：

arm-linux-*和 arm-elf-*，两者区别主要在于使用不同的C库文件。arm-linux-*使用

GNU的Glibc，而arm-elf-*一般使用 uClibc/uC-libc或者使用REDHAT专门为嵌入式系统

的开发的C库newlib.Glibc。uClibc/uC-libc以及 newlib都是C语言库文件，只是所应

用的领域不同而已，Glibc是针对PC开发的，uClibc/uC-libc是与Glibc API兼容的小型

化C语言库，实现了Glibc部分功能。

关于uClibc/uC-libc的说明，详见如下：

There are two libc libraries commonly used with uClinux. uC-libc and

uClibc. They are quite different despite their similar names. Here is a

quick overview of how they are different.

uC-libc is the original library for uClinux. It was based on sources

from the Linux-8086 C library which was part of the ELKs project with m68000

support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete

libc implementation, however, some of the API's are a little non-standard

and quite a few common libc routines are not present. Currently it has

stable support for m68000, ColdFire and ARM (Non-MMU) architectures. It was

primary design goal is to be small and light weight. It does try to conform

to any standards, although its API tries to be compatible with most libcs,

it is not always exactly the same.

The uClinux distribution provides an environment that can compile using

either uC-libc or uClibc depending on your needs. For m68000 and Coldfire

platforms it is generally better to chose uC-libc as it supports shared

libraries and is the most commonly used libc for these CPUs. uClibc also

works quite well with almost all platforms supported by the distribution.

Which libc you choose to use will be decided by your requirements

uClinux有两个经常使用的libc库：uC-libc和uClibc。虽然两者名字很相似，其实有差

别，下面就简单的介绍一下二者的不同之处。uC -libc是最早为uClinux开发的库，是

Jeff Dionne和Kenneth Albanowski为在EKLs项目中支持m68000在Linux-8086 C库源码

上移植的。uC-libc是一个完全的libc实现，但其中有一些api是非标准的，有些libc的

标准也没有实现。uC-libc稳定地支持 m68000，ColdFire和没有MMU的ARM。其主要设计

目标是“小”、"轻"，并尽量与标准一致，虽然它的API和很多libc兼容，但是似乎并

不像它期望的那样和所有标准一致。

uClibc就是为了解决这个问题从uC-libc中发展出来的。它的所有API都是标准的(正确

的返回类型，参数等等)，它弥补了uC-libc中没有实现的libc标准，现在已经被移植到

多种架构中。一般来讲，它尽量兼容glibc以便使应用程序用uClibc改写变的容易。

uClibc能够在标准的 VM linux和uClinux上面使用。为了应用程序的简洁，它甚至可以

在许多支持MMU的平台上被编译成共享库。Erik Anderson在uClibc背后做了很多的工

作。uClibc支持许多系列的处理器：m68000，Coldfire，ARM，MIPS，v850， x86，

i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不断增加的平台支持显示uClibc

能够很容易的适应新的架构。uClinux发行版提供了环境能够让你选择使用uC-libc或是

uClibc编译。对于m68000和Coldfire平台来说，选择uC-libc还是稍微好一点，因为它

支持共享库，而共享库是这些cpu经常使用的 libc.uClibc也几乎和所有的平台都能很

好的工作。选择哪种libc取决于你的需求。

newlib 是一个用于嵌入式系统的开放源代码的C语言程序库，由libc和libm两个库组

成，特点是轻量级，速度快，可移植到很多CPU结构上。newlib实现了许多复杂的功

能，包括字符串支持，浮点运算，内存分配(如malloc)和I/O流函数(printf，fprinf()

等等)。其中libc提供了c 语言库的实现，而libm提供了浮点运算支持。

在为ARM交叉编译gcc编译器时，对gcc指定不同的配置选项时，使用的C语言库就不同，

gcc编译器默认使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，当使用

--with-newlib时，gcc编译器不使用Glibc。当没有交叉编译Glibc时，可以使用

--with-newlib禁止连接Glibc而编译bootstrap gcc编译器。从gcc源目录下的

config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影响gcc连接C语言

库，t-linux(--target=arm-linux)默认使用Glibc，-arm-elf(--target=arm-elf)使用

- Dinhibit_libc禁止连接Glibc，这时我们就可以使用newlib等其他C语言库编译GCC工

具链。

虽然GCC工具链配置了不同的的C语言库，但由于这些C语言库都可以用来支持GCC，它们

对核心数据的处理上不存在较大出入。因而arm-linux-* 和 arm-elf-*区别主要表现在

C语言库的实现上，例如不同系统调用，不同的函数集实现，不同的ABI\启动代码以及

不同系统特性等微小的差别。

arm-linux-*和 arm-elf-*的使用没有一个绝对的标准，排除不同库实现的差异，gcc可

以编译任何系统。arm-linux-*和 arm-elf-*都可以用来编译裸机程序和 *** 作系统，只

是在遵循下面的描述时系统程序显得更加协调：

arm-linux-*针对运行linux的ARM机器，其依赖于指定的C语言库Glibc，因为同样使用

Glibc的linux而使得arm-linux-*在运行linux的ARM机器上编译显得更加和谐。

arm-elf-*则是一个独立的编译体系，不依赖于指定的C语言库Glibc，可以使用newlib

等其他C语言库，不要求 *** 作系统支持，当其使用为嵌入式系统而设计的一些轻巧的C语

言库时编译裸机程序(没有linux等大型 *** 作系统的程序)，如监控程序，bootloader等

能使得系统程序更加小巧快捷。

---