This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Separate bss sections for kernel and application
- From: Ian Gilmour <ian dot gilmour at ffei dot co dot uk>
- To: mark dot retallack at siemens dot com
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 12 Dec 2002 08:50:56 -0000
- Subject: RE: [ECOS] Separate bss sections for kernel and application
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