[M32C-ELF] : Improper follow-up of bss section

[M32C-ELF] : Improper follow-up of bss section

[Ina Pandit]

Hi,

I have downloaded latest GCC and Binutils sources from FSF for M32C
port. Using these sources, I could successfully build the cross
toolchain i.e. m32c-elf-*.

I have observed the following behavior while building an application,
Case 1 - Initialized global variables are not present in the application.
	 (data section is empty). If I specify the locations of data
	 section and bss section in the linker script in the
	 following manner and build the application,
    
 	 .data 0x00000400 :
 	 {
 	      _data = .;
 	      *(.data)
 	      *(.data.*)
 	      _edata = .;
 	 }

 	 .bss :
 	 {
 	      _bss = .;
 	      *(.bss)
 	      *(COMMON)
 	      _ebss = .;
 	      _end = .;
 	 }
 	 
 	 the bss section is located at the location 0x000000 instead
 	 of 0x000400. The value of the variable "_bss" is 0x000000.
 	 The value of the variables "_ebss" and "_end" is 0x000000.
	 This can be verified from the map file.
	 In this case the location counter is not incremented
	 properly. In case of H8 and SH tool chains, the bss section
	 follows the data section correctly.
	 
Case 2 - One initialized global variable is present in the application
	 (E.g. int i = 1;).
	 If I build the application with the above mentioned linker
	 script, the bss section is located at 0x000402.
	 The value of the variable "_bss" is 0x000402.
	 The value of the variables "_ebss" and "_end" is 0x000402.
	 This can be verified from the map file.
	 
	 Thus, for the proper follow-up of the bss section (i.e. to
	 increment the location counter correctly), the data section
	 should not be empty. Is this behavior expected?
	 
Case 3 - No initialized global variable is present in the application
	 (data section is empty) but following linker script is used,
         
       	 MEMORY
             {
               ram (rw) : o = 0x0000400, l = 31k
               rom (rx) : o = 0x000E000, l = 256k
	 }
	 
	 .data 0x00000400 :
	 {
	      _data = .;
	      *(.data)
	      *(.data.*)
	      _edata = .;
	 } > ram
	 
	 .bss :
	 {
	      _bss = .;
	      *(.bss)
	      *(COMMON)
	      _ebss = .;
	      _end = .;
	 } > ram
	 
	 In this case the bss section follows the data section 
	 correctly i.e. bss section is located at address 0x000400
	 and not 0x000000 (as in case 1).
	 In this case the location counter is incremented correctly.
	 
The above behavior is observed for all m32c targets, i.e. r8c, m16c,
m32c and m32cm.
Is this behavior expected?
Linker script similar to the script specified in case 1, works properly
with H8 and SH tool chains (modified according to their memory maps).
Why does it not work with M32C tool chain?
Do I need to use "MEMORY" command in the linker script as in case 3.

Thanks in advance.

Regards,
Ina Pandit
KPIT Cummins InfoSystems Ltd.
Pune, India

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools were released on February 1, 2006.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~               

Re: [M32C-ELF] : Improper follow-up of bss section

[DJ Delorie]

> I have downloaded latest GCC and Binutils sources from FSF for M32C
> port. Using these sources, I could successfully build the cross
> toolchain i.e. m32c-elf-*.

You didn't download newlib?  It has all the runtime code and linker
scripts for the M32C targets.  Writing linker scripts for embedded
targets is tricky; please make sure you understand how the existing
scripts work before trying to write your own.