Understanding memory usage in Studio's output

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Evening everyone,

 

I started working with various ATSAM devices in AS7 after a decade of so of AVR; and one of the things that's been really bugging me, is understanding the memory usage output from Studio.

 

Two main questions:

 

1) I thought I understood that the stack size is set by __stack_size__ in the linker scripts generated by Studio (as per this), but - it doesn't appear to be. Changing the __stack_size__ changes the size of bss memory section. Why?

 

		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-size.exe" "x.elf"
		   text	   data	    bss	    dec	    hex	filename
		   1272	   1076	   8260	  10608	   2970	x.elf
	Done executing task "RunCompilerTask".
	Task "RunOutputFileVerifyTask"
				Program Memory Usage 	:	2348 bytes   0.9 % Full
				Data Memory Usage 		:	9336 bytes   28.5 % Full
				Warning: Memory Usage estimation may not be accurate if there are sections other than .text sections in ELF file
	Done executing task "RunOutputFileVerifyTask".

2) Statically allocated variables initialised to zero do not seem to cause an increase in the .data section size, as expected (expected, by me at least - not to say that is correct) - but rather in the .bss. My understanding was .data was for initialised variables, and .bss was not for uninitialized variables. The top rated answer on this Stackoverflow post suggests arrays initialised to 0 always end up in .bss, not .data. I can prove this easily just by initialising any element of an array to non-zero, and the array ends up in .data, not .bss. So perhaps this is a more generic question that I thought, why do zero initialised arrays end up in .bss? Is this implementation defined, or hardware dependant?

 

Cheers!

Last Edited: Tue. Nov 23, 2021 - 01:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

why do zero initialised arrays end up in .bss?

These days it is defined standard that .bss is zero by the C startup code, so variables that initialized to zero get put there in order to save space in the object file.  (int arr[1000]= {0}; would take 4k in .data, but is just merged into "bss_end - bss_start must be zeroed" if it's in .bss.

 

Changing the __stack_size__ changes the size of bss memory section. Why?

Which chip, exactly?  The stack doesn't seem to be included in the .bss size of some things I compiled for SAMD21 or SAM3x

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
These days it is defined standard that .bss is zero by the C startup code, so variables that initialized to zero get put there in order to save space in the object file.  (int arr[1000]= {0}; would take 4k in .data, but is just merged into "bss_end - bss_start must be zeroed" if it's in .bss.

 

Understood, thank you.

 

westfw wrote:
Which chip, exactly?  The stack doesn't seem to be included in the .bss size of some things I compiled for SAMD21 or SAM3x

 

SAMC21J18A and SAMC21N18A. It was late last night, so I've just double checked - and yes, increasing the stack size increases the .bss size!

 

I've also just tried with a random SAMD21, SAMD21J18A, as per your attempt. I see exactly the same behaviour, increasing __stack_size__ increases .bss.

 

Switched back to the SAMC21 devices, no change .bss still increases in stack size.

 

EDIT - different platform, but same issue here. Here is my build output switching between a stack size of 0x3000 and 0x2000.

 

0x3000 (12288 decimal)
		   text	   data	    bss	    dec	    hex	filename
		   1244	   1076	  17380	  19700	   4cf4	x.elf

0x2000 (8192 decimal)
		   text	   data	    bss	    dec	    hex	filename
		   1244	   1076	  13284	  15604	   3cf4	x.elf

 

Last Edited: Tue. Nov 23, 2021 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks like the "size" command lumps any .section with a size into bss, if it's not in .text or .data.

https://github.com/CyberGrandCha... :

static void
berkeley_sum (bfd *abfd ATTRIBUTE_UNUSED, sec_ptr sec,
	      void *ignore ATTRIBUTE_UNUSED)
{
  flagword flags;
  bfd_size_type size;

  flags = bfd_get_section_flags (abfd, sec);
  if ((flags & SEC_ALLOC) == 0)
    return;

  size = bfd_get_section_size (sec);
  if ((flags & SEC_CODE) != 0 || (flags & SEC_READONLY) != 0)
    textsize += size;
  else if ((flags & SEC_HAS_CONTENTS) != 0)
    datasize += size;
  else
    bsssize += size;
}

 

Now, I don't quite understand why the Studio builds have a .stack section, while builds with Arduino don't (and therefore don't include the stack size in the .bss section report.)