This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: partial c++ code binary update on embedded target
- From: Joel Sherrill <Joel dot Sherrill at OARcorp dot com>
- To: nick clifton <nickc at redhat dot com>
- Cc: Riccardo Manfrin <riccardomanfrin at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 22 Aug 2013 11:53:22 -0500
- Subject: Re: partial c++ code binary update on embedded target
Can't you also link a base image and layer additions in it using the -R or --just-symbols argument. Then put individual subsystems far enough apart in memory to allow for updates.
--joel
nick clifton <nickc@redhat.com> wrote:
Hi Riccardo,
> 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?
Yes - use multiple unique sections... Map the .text sections into one
specific, unique output section, the .data sections into another and so on.
> My answer to these two points is to use a linkerscript similar to the
> following:
Right - this is the way to do it.
> 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
> this)?
So use wildcards. For example if you have all of the fixed parts of the
application in one directory and all of the upgradeable parts in another
directory then your script could look like this:
.dll_rom : { upgradeable/*(.text) } >rom
.text : { fixed/*(.text) }
.dll_ram : { upgradeable/*(.data) } >ram AT>rom
.data : { fixed/*(.data) }
Cheers
Nick