Creating position independent programs that run from any location

[lpcware]

Content originally posted in LPCWare by Blackclaws on Thu Jul 30 04:12:19 MST 2015
So I am currently working on a project where I would like to upload additional firmware onto my device.

I did manage to adapt the secondary usb bootloader example so that I can load firmware.

The problem I have now is that I want this firmware to be runnable from any position in ram (minus alignment requirements of course).

So far the only way I have managed to actually run the firmware is if I build it with the final location in mind and then do a vector table relocation.

However since I would like the code to run from multiple possible locations I tried to build it position independent. This however did not have the desired effect as the vector table apparently hard codes the memory location of the vector functions during linking and does not create position independent code at all. I did enable the position independent option but this didn't change the vector table problem in the slightest. Do I manually have to modify the vector table so that its entries point to the right memory location?

I'm now not sure if this is an actual limitation of the vector table or just a problem with how LPCExpresso manages linker scripts or the way the startup files are designed.

I would be glad if anyone could either flat out tell me how to build a project so that it loads from any memory location or point me towards some documents which tell me how to do it or simply confirms that it isn't possible at all.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 30 04:22:11 MST 2015

You are correct, in that the the generated linker script is placing code at fixed, known addresses. As well as compiling your binaries for position independence, you would also need to provide your own linker script that does not place the text/data/bss sections into named memory areas.

However, to make truly position independent code AND position independent data, requires you to write an application loader that reads the AXF file (not a binary) and provides the appropriate fix-ups. This is normally done by on operating system (not an RTOS).