This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Separate bss sections for kernel and application


Thank you to everyone that help, I have now found a way of doing it. First
the kernel is compiled and target.ld and libtarget.a are produced. Second,
all the application objects are compiled into one library called tmpapp.o.
The bss line in the target.ld file is modified with the following line:

    .bss   ALIGN (0x10)  :     	{ __bss_start = ABSOLUTE (.);
__app_bss_start = ABSOLUTE (.);	obj/tmpapp.o(.dynbss*) obj/tmpapp.o(.bss*)
obj/tmpapp.o(COMMON)	__app_bss_end = ABSOLUTE (.);	__kern_bss_start =
ABSOLUTE (.);	. = . ;	*(.dynbss*) *(.bss*) *(COMMON)	__kern_bss_end =
ABSOLUTE (.);	__bss_end = ABSOLUTE (.); }	>  ram   

This now allows me to clear from __kern_bss_start to __kern_bss_end on every
startup and from __app_bss_start to __app_bss_end when the data is trashed.


Thanks again to everyone.

Mark Retallack

-----Original Message-----
From: Ian Gilmour [mailto:ian.gilmour@ffei.co.uk]
Sent: 12 December 2002 08:51
To: mark.retallack@siemens.com
Cc: ecos-discuss@sources.redhat.com
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
> 


Siemens Plc 
Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. 
Registered no: 727817, England. 

This communication contains information which is confidential and 
may also be privileged. It is for the exclusive use of the addressee. 
If you are not the addressee please note that any distribution, 
reproduction, copying, publication or use of this communication 
or the information in it is prohibited.  If you have received this 
communication in error, please contact us immediately and also 
delete the communication from your computer. 



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]