Re: [ECOS] Separate bss sections for kernel and application

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Mark" == Retallack, Mark (Poole) <mark.retallack@siemens.com> writes:

    Mark> I have a quick question:
    Mark> Is there any way of setting the build system up so that the
    Mark> target binary contains two bss sections (with separate
    Mark> names)?

    Mark> The problem is that we have a lot of very old code that
    Mark> contains lots of global variables that need to be preserved
    Mark> on power-up/down. The ideal solution would be to separate
    Mark> the kernel (target.a) library bss section from application's
    Mark> bss section. This would allow us to reset all the kernel
    Mark> data but keep the application data intact on start-up. It
    Mark> would take too long to re-design/re-code our application so
    Mark> we need a compile time solution.

    Mark> We have tried specifying separate paths to the library and
    Mark> application objects within the target.ld file with no
    Mark> success and any suggestions would be gratefully welcomed.

There is no simple way of doing this, but there are a couple of things
you could try.

One approach would be to use the xxx-yyy-objcopy program appropriate
for your architecture, with the --rename-section option to change the
.bss section to whatever you need. Run this on the .o files for your
application prior to linking. Note that this sort of thing is rather
application-specific, so you will probably find it easier to change
the build procedure for your application than the way eCos gets built.
You will also need to customise the linker script generated by the
eCos build to place this new section somewhere approprate in memory.

Another approach is to modify the application source code and use
__attribute__((section (...))) on the variable definition. Note that
for uninitialized data you may need to use -fno-common or the
nocommon attribute, see the gcc info pages. This is a good approach if
you can identify a small number of variables that need to be treated
in this way. The linker script will obviously have to be updated as
before.

Or, if you can identify the variables but do not want to change the
source code, then you could try compiling the application code with
-fdata-sections. That should cause all variables to go into their own
sections, so for example an initialized variable x would go into a
section .data.x. In the linker script you could then insert something
like the following before the main .data section:

    .preserved_data ALIGN(0x04): { .data.x ... } > ram

I believe the linker will place variables in the first section it can,
hence .preserved_data should precede .data. I am not sure how well
this approach will work for uninitialized variables.

There have been occasional discussions about a linker script editing
tool which would make it easier to do this sort of thing. For example
this would examine the linker map to find out what variables and
functions actually ended up linked into the final executable, and
allow the user to control the location of each one. Such a tool is not
yet available for eCos.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss