partial c++ code binary update on embedded target

Riccardo Manfrin
Wed Aug 21 07:41:00 GMT 2013

I'm writing a C++ application for an embedded ARM-CM3 target. The 
application is made by a fixed core (flashed once and forever) and an 
upgradeable part. The upgradeable part is a collection (a "library") of 
classes, virtual tables, function definitions and global data/bss 

The library has a symbol table defined at compile time (no dynamic 
relocation) that specifies for any exported symbol the absolute position 
it can be found :

0x8000 0000 lib_foo0: 0x8000 0100
0x8000 0004 lib_foo1: 0x8000 0040

The application fixed part knows the symbol names and the type of object 
associated to them and can access the correct address through variable 

Maybe I'm doing it wrong, but my idea is to compile the application as a 
single binary and place all the upgradeable part in a dedicated section 
at an offset corresponding to a dedicated region of flash memory.

If the upgradeable part needs to be updated I just have to recompile the 
whole application, strip the "upgradeable" special section and 
(over)write the dedicated flash region with the new version of the 
stripped library.

I have two concerns:
1) How do I force the upgradeable part to be placed in a separate 
section (lets call it the ".upgradeable_section")? For a class, the 
"__attribute__ ((section(".upgradeable_
section")))" does not work and a class can also have a virtual table 
which is automatically handled by the compiler.

2) If I place all the .data, .bss and .text into a unique section, is 
there a way to identify those parts of the library that are read/write 
and need to be copied in RAM at startup?

My answer to these two points is to use a linkerscript similar to the 

rom (rx) : ORIGIN = 0x01000000, LENGTH = 512K
ram (rwx) : ORIGIN = 0x00000000, LENGTH = 32K
} > rom


* Put here all files and sections going in ROM (flash)
} > rom

* Put here all files and sections going in RAM
foo_dll.o(.data .bss)

} >ram AT>rom

Is this solution applicable? Is there a better one than writing each 
single file of the library in the linkerscript (I feel really bad doing 
For instance, I see that the .text section can be made by several 
suffixes (e.g., ...), is this exploitable in some way?

Sorry in advance for any unforgivable, embarrassing mistake I'm writing 
through this post and thanks for the support.

More information about the Gcc-help mailing list