Ошибка сегментации, вызванная / устраненная путем изменения порядка файлов исходного кода в Makefile

Я занимаюсь разработкой программного обеспечения на встроенной платформе и продолжаю получать необъяснимые (для меня) ошибки сегментации. Я надеялся получить отладочные идеи от тех из вас, у кого больше опыта работы со встроенными платформами. Я не смог найти полезную информацию с помощью поиска Google.

Подробности:

  • C ++, скомпилированный с помощью GCC-ARM toolchain (4.9.3)
  • Процессор ARM Cortex-M3 (если вам интересно, на плате разработчиков LPC1768)
  • Я могу предотвратить ошибку сегментации, изменив порядок сборки исходных файлов (то есть порядок файлов в файле Makefile). Этот порядок файлов по существу произвольный.
  • Ошибка сегментации всегда возникает во время создания объектов класса в конструкторе класса и происходит во время запуска программы (до того, как достигается main ()).
  • Если я закомментирую код в данном конструкторе класса, где происходит ошибка, то ошибка будет возникать в конструкторе несколько других создание объекта класса (конечно, другого класса).

Я в недоумении. Похоже, что экземпляр объекта записывает поверх другой памяти, чтобы вызвать segfault, но не должно ли ядро ​​предотвратить это? Я не пишу прямо в память здесь, я просто делаю обычную реализацию объекта.

Мое предположение: я считаю, что я читал, что архитектура на основе ARM помещает и ПЗУ, и ОЗУ в один и тот же блок флэш-памяти. Изменение порядка выполнения файла изменяет порядок объектов в ПЗУ. При запуске вышеупомянутый экземпляр объекта в блоке RAM случайно перезаписывает некоторую память ROM. В одном случае порядка исходных файлов перезаписанная память не имеет значения и, следовательно, не вызывает segfault, а в другом случае это имеет значение и вызывает segfault.

Это предположение может показать, как мало я знаю о том, как работают жесткие обработчики ошибок. Пожалуйста, прости мою наивность со встроенными платформами.

Любые мысли о том, что я мог бы расследовать? Этот тип проблемы характерен для определенного источника или ошибки Makefile?

Вот пара примеров segfaults:

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?)

2

Решение

Задача ещё не решена.

Другие решения