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

[Ian Gilmour <ian dot gilmour at ffei dot co dot uk>]

Mark,

I haven't tried it, but I'd have thought something like the following in
your locate file should work, after you've defined where ram_kernel and
ram_appl are located.

    /* locate kernel un-initialised data */
    .kernel_bss  :
    {
        _kernel_bss_start = .;
        path/to/kernel_module1.o(.bss)
        path/to/kernel_module2.o(.bss)
        /* ...etc... */
        _kernel_bss_end = .;
    } > ram_kernel

    /* locate remaining un-initialised data */
    .bss  :
    {
        _bss_start = .;
        *(.bss)
        *(COMMON)
        _bss_end = .;
        _end = .;
    } > ram_appl

I've used something similar (albeit in a non-ecos environment) for locating
specific .text modules in specific regions. 
N.B. If you're kernel_moduleX.o files aren't left around as part of your
current build you'll need to make them .PRECIOUS to leave them around for
the locate phase.


cheers,

Ian

> -----Original Message-----
> From: Bart Veer [mailto:bartv@ecoscentric.com]
> Sent: Wednesday, December 11, 2002 5:22 PM
> To: mark.retallack@siemens.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] Separate bss sections for kernel and application
> 
> 
> >>>>> "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
> 

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