I am building a c++ application on an nxp imx rt 1024 which has an arm cortex-m7 cpu. We have the strong need for OTA (over the air update) thus I created a customer bootloader, and the actual firmware app. The firmware app is compiled with -fpic -mpic-register=r9 -msingle-pic-base -mno-pic-data-is-text-relative. Vector tables and .got are moved to sram, and my custom bootloader jumps to either app1 or app2.
All is good in my test project, until I *do not deploy app1*. Meaning, I am not uploading the app to its original compile time location where app1 would normally sit. Instead, I just upload app2, with an arbitrary offset of 0x10000. In the booloader I compensate the jump to app2 with that same 0x10000 and I modify the ISR addresses in the vector table so that they are pointing towards the ISR routines in the address space of app2.
All is good, until I get to my startup code. There, I update r9 register, and do the mandatory copying to sram (in my case, the .got section, and the regular .data section which needs to be copied from sram to flash. After that, my startup code needs to call __lib_init_array, to properly initialize the constructors/destructors. This hard faults my application.
After some investigation, I became somewhat concerned that the library (libc_nano.a) is not compiled with -fpic. And, when googling a bit more specific on that, I see more people experiencing the same thing. While googling I came across some oracle page where they explain that "crti.o" and "crtn.o" are compatible with position independence.
Some questions I hope to get answered here:- Am I correct that libc_nano is not compiled for position independence?
- Is there a reason to not compile libc_nano with -fpic? Is it at all possible?
- And of course, most importantly, how can I achieve my c++ project to become truly position independent?
PS: I also tried to use the "libc.a" and "libcr_newlib_nohost.a" instead. But they seem to suffer from the exact same problem.
I really hope I am missing some compiler/linker switch which make all problems go away :)
(it's also hard to imagine that position independence combined with c++ simply is not possible.... right?)
I'm not explicitly familiar with libc_nano, but the equivalent microlib C library provided with Arm Compiler is a minimal C library with many restrictions.