Segmentation fault caused/avoided by changing source file order in Makefile

I'm developing software on an embedded platform and keep getting inexplicable (to me) segmentation faults. I was hoping to get some debugging ideas from those of you with more embedded platform experience. I couldn't find any useful information with a google search.

Details:

• C++ compiled with GCC-ARM toolchain (4.9.3)
• ARM Cortex-M3 processor (on a LPC1768 dev board, if you're curious)
• I can prevent the segmentation fault by modifying the build order of the source files (i.e., file order in the Makefile). This file order is essentially arbitrary.
• The segmentation fault always occurs during the instantiation of class objects in the class constructor, and occurs during program startup (before main() is reached).
• If I comment out the code in the given class constructor where the segfault occurs, the segfault will occur in the constructor of some other class object instantiation (of a different class, of course).

I'm at a loss. It looks like the object instantiation is writing over other memory to cause the segfault, but shouldn't the kernel prevent that? I'm not writing directly to memory here, I'm just doing a normal object instantiation.

My guess: I believe I've read that ARM-based architecture puts both the ROM and the RAM on the same flash memory block. Changing the file make order changes the order of the objects in the ROM. Upon startup, the aforementioned object instantiation in the RAM block is overwriting some ROM memory inadvertently. In one source file order case, the memory overwritten doesn't matter and therefore doesn't trigger the segfault, and in the other case it does matter and does trigger the segfault.

That guess may reveal how little I know about how hard fault handlers work. Please forgive my naiveté with embedded platforms.

Any thoughts on what I might investigate? Is this sort of issue characteristic of a particular source or Makefile error?

Here are a couple of examples of the 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?)

and

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