Best use of .bss and other sections

[powerNZ]

Hi All,

We now have a CodeWarrior version of our startup file which is pleasing progress.

Now I need to get my head around the .bss, .data and the use of sections in general.

If I am right .data is a directive to the linker as to which memory section to place the variable in. This name also ripples through to the ELF file for debugging.

Does this mean that I need to specify the memory section in my source file so every variable is specifically located?

Would the same apply to code or is .text assumed for executable code?

I have read the description in the 'targeting_embedded_68K_Coldfire' documentation but the examples don't extend to real code usage.

Any comments welcome,

Graham

[stanish]

Hello Graham,

Usually there are several predefined sections that CodeWarrior Linker uses to separate different objects into these sections. (I believe it's the same with CW for 68K)

.text...application code

.rodata...literal values and initialization values in the application’s source code

.sdata...initialized small global data

.data...initialized global data
.sbss...uninitialized global small data

.bss...uninitialized global data

...

These are default predefined sections so you don't have to explicitly define section for them in the source code if you require the code/data/constant to be placed there. The Linker Command file defines where these sections should be physically allocated into memory.

stanish

[powerNZ]

Hello Stanish,

OK - maybe I am on the wrong track here so let me clarify the situation...

The newly created startup file compiles yet results in linker errors such as 'undefined : "_END_BSS"' (or _END_SBSS, _SDA_BASE, _SP_INIT, _START_BSS, _START_SBSS and _S_romp).

I presumed that the references to the start or end of BSS implied that I had not used any such section in the source. Is there an example project that would demonstrate such items? The provided sample 'hello world' programs are SO minimal as to not be worth the disk space they occupy.

When they talk of 'initialised' (or 'uninitialised') are they referring to clearing the memory to 0x0000 (or not) or is it that a value has been included in the variable declaration?

Regards,

Graham

[CrasyCat]

Hello

Basically it works as follows:

initialized variables are non-constant variable defined with an initialization value.

Uninitialized variables are variables defined without an initialization value.

So for example

int Tab1[8] = {0, 1, 2, 3, 4, 5, 6, 7}; will be allocated in section .data

int Tab2[8]; will be allocated in .bss.

const int Tab3[8] = {0, 1, 2, 3, 4, 5, 6, 7}; will be allocated in section .rodata

and if you specify small data are data smaller than 8 bytes,

int Tab4[2] = {0, 1, 2}; will be allocated in section .sdata

int Tab5[2]; will be allocated in .sbss.

The startup code will modify both the initialized and uninitialized data.

Initialized data will be set to their initialization value.

uninitialized data will be set to 0.

If you have no object allocated in .bss, BSS_START will be equal to BSS_END.

If you create your project starting from a stationery everything should be set up appropriately.

CrasyCat

[powerNZ]

Hi there,

That all seems fairly straight forward - if I wished to place a particular variable in a specific memory area (say for example a battery backed RAM) how would I over-ride the automatic space allocation?

Confession time! My problem project was started without the aid of stationery - so at your prompting I have started one based on stationery and copied all my source files to it. This has raised a few issues:

 1) The target processor is not supported so we need to use a 'near' relative (68360quad where we use the 68332) so we need to alter the project options and names accordingly.

 2) The stationery produces a large folder structure that is quite dissimilar to our preferred structure and I haven't fully worked out how to correct it

 3) The stationery based project compiles and links OK which means that somewhere in my non-stationery based project there is a configuration error but I have been unable to locate it. Suggestions welcome.

IMHO: The use of stationery to create a project should simply preset the options/configuration. It should always be possible to do this manually and achieve the same result.

Comments and suggestions welcome,

Graham 

[powerNZ]

Hi All,

Good progress today!

I made a file by file, then line by line comparison of the two projects. From this I made some extensive changes to the LCF file and the project progressed through the linking stage to report that one of the memory areas overflowed.

This returns me to the question I posted on my previous posting, which I will repeat here so it is clear:

How is the automatic space allocation over-ridden in the LCF file so that particular variables can be placed in specific memory segments?

I hope to progress this today, but as always comments and pointers are welcome!

Regards,

Graham

[CrasyCat]

Hello

If you want to allocate a variable at a specific address, you need to define it in a user defined section and then place that section accordingly in your .lcf file.

To define a variable in a user defined section use following notation:

#pragma define_section myData ".myData" ".myBssData"

__declspec(myData) int temp;

__declspec(myData) int initTemp = 10;

This will place variable temp in .myBssData and variable initTemp in .myData.

Then you need to place these sections accordingly in the .lcf file.

For example:

MEMORY {
 TEXT (RX) : ORIGIN = 0x10002000, LENGTH = 0x0
 DATA (RW) : ORIGIN = AFTER(TEXT), LENGTH = 0x0
 MYDATA(RW)RIGIN = 0x2000, LENGTH =0x0
}

SECTIONS {
 .myData :
 {
  *(.myData)
  *(.myBssData)
 } > MYDATA
...

} 

In the MAP file you will see something like that:

# .myData
  00002000 00000004 .myBssData temp (main.c)

I hope this helps

CrasyCat