Question

我正在开发嵌入式平台上的软件，并且一直无法解释（对我而言）分段错误。我希望得到一些具有更多嵌入式平台经验的调试思路。我在谷歌搜索中找不到任何有用的信息。

详细说明：

使用GCC-ARM工具链（4.9.3）编译的C ++
ARM Cortex-M3处理器（在LPC1768开发板上，如果你很好奇的话）
我可以通过修改源文件的构建顺序（即Makefile中的文件顺序）来防止分段错误。此文件顺序基本上是任意的。
分段错误总是在类构造函数中实例化类对象期间发生，并且在程序启动期间（在到达main（）之前）发生。
如果我注释掉了发生段错误的给定类构造函数中的代码，那么段错误将出现在其他类对象实例化（当然是另一个类）的构造函数中。 / LI>

我很茫然。看起来对象实例化正在写入其他内存以导致段错误，但 内核不应该阻止它吗？ 我不是直接写入内存，我我正在做一个普通的对象实例化。

我的猜测：我相信我已经读过基于ARM的架构将ROM和RAM放在同一个闪存块中。更改文件生成顺序会更改ROM中对象的顺序。在启动时，RAM块中的上述对象实例化会无意中覆盖某些ROM存储器。在一个源文件顺序的情况下，覆盖的内存无关紧要，因此不会触发段错误，而在另一种情况下，它确实很重要并且会触发段错误。

这个猜测可能揭示我对故障处理程序的工作方式知之甚少。请原谅我的嵌入式平台天真。

关于我可能会调查的任何想法？这种问题是特定来源或Makefile错误的特征吗？

以下是段错误的几个例子：

Program received signal SIGSEGV, Segmentation fault.
0x00003cde in HardFault_Handler ()
(gdb) where
#0  0x00003cde in HardFault_Handler ()
#1  <signal handler called>
#2  dataComm::dataComm (this=0x10000218 <dc>) at dataComm/dataComm.cpp:12
#3  0x000002e6 in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535) at main.cpp:22
#4  _GLOBAL__sub_I_dataIn () at main.cpp:87
#5  0x00006b32 in __libc_init_array ()
#6  0x0000016e in _start ()
#7  0x0000016e in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

和

Program received signal SIGSEGV, Segmentation fault.
0x00003586 in HardFault_Handler ()
(gdb) where
#0  0x00003586 in HardFault_Handler ()
#1  <signal handler called>
#2  0x00004f94 in spi_format ()
#3  0x000044d2 in mbed::SPI::aquire() ()
#4  0x0000205e in FSM::FSM (this=0x1000070c <fsm>)
    at FiniteStateMachine/FSM.cpp:54
#5  0x0000097c in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535) at initExoVars/initExoVars.cpp:37
#6  _GLOBAL__sub_I_txtLeft () at initExoVars/initExoVars.cpp:215
#7  0x0000606a in __libc_init_array ()
#8  0x0000016e in _start ()
#9  0x0000016e in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

通过更改Makefile

0 个答案: