ZakKemble / avr-gcc-build

https://blog.zakkemble.net/avr-gcc-builds/
60 stars 9 forks source link

GCC doesn't seem to know the size of memory available #5

Closed armandas closed 8 months ago

armandas commented 1 year ago

I am building a project for ATmega640 using GCC 12.1. I'm passing a -Wl,--print-memory-usage flag to the linker to get the memory usage, but GCC thinks that the device has 128KB of flash, instead of 64KB. The RAM and EEPROM sizes are also wrong.

Linker flags: -mmcu=atmega640 -fno-exceptions -fno-rtti -Wl,--gc-sections -Wl,--print-memory-usage

Output:

Memory region         Used Size  Region Size  %age Used
            text:       49628 B       128 KB     37.86%
            data:         748 B      65440 B      1.14%
          eeprom:          0 GB        64 KB      0.00%
            fuse:          0 GB          3 B      0.00%
            lock:          0 GB         1 KB      0.00%
       signature:          0 GB         1 KB      0.00%
 user_signatures:          0 GB         1 KB      0.00%

When the command from #3, the correct percentage is displayed:

Device: atmega640

Program:   49628 bytes (75.7% Full)
(.text + .data + .bootloader)

Data:        332 bytes (4.1% Full)
(.data + .bss + .noinit)

Unfortunately, this issue means that compiler does not detect when the code exceeds the available memory.

The issue is not present on GCC 5.4, that is bundled with the Microchip Studio.

armandas commented 1 year ago

Update: the issue goes away when using the Atmel DFP (-B ... flag)

mobacon commented 1 year ago

Did also run into this problem. The -B flag does not work for me. What flags exactly you use?

Furthermore the SysProgs compiler (only for Windows) works out of the box with correct region size. So somehow it must be possible to get the correct behavior also on Linux.

armandas commented 1 year ago

@mobacon Did you pass the right argument to -B? I point it to the extracted DFP like this:

-B _deps/atmegadfp/gcc/dev/atmega640
sprintersb commented 8 months ago

Reason is that Binutils works on emulation level, i.e. is knows -mavrxmega2 or -mavr51, and the layout of MEMORY regions comes from the emulation default. For example, the top of the default linker scripts read something like (here from avr51.x):

__TEXT_REGION_ORIGIN__ = DEFINED(__TEXT_REGION_ORIGIN__) ? __TEXT_REGION_ORIGIN__ : 0;
__TEXT_REGION_LENGTH__ = DEFINED(__TEXT_REGION_LENGTH__) ? __TEXT_REGION_LENGTH__ : 128K;
__DATA_REGION_ORIGIN__ = DEFINED(__DATA_REGION_ORIGIN__) ? __DATA_REGION_ORIGIN__ : 0x800100;
__DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? __DATA_REGION_LENGTH__ : 0xff00;
...
MEMORY
{
  text   (rx)   : ORIGIN = __TEXT_REGION_ORIGIN__, LENGTH = __TEXT_REGION_LENGTH__
  data   (rw!x) : ORIGIN = __DATA_REGION_ORIGIN__, LENGTH = __DATA_REGION_LENGTH__
  ...
}

Hence, when symbols like __TEXT_REGION_LENGTH__ are not defined, the core specific defaults are used which are large enough so that all MCUs in that core family will fit.

A canonical place to define these symbols is in the startup code. Stock AVR-LibC currently does not define respective symbols, but there is https://github.com/avrdudes/avr-libc/issues/936 to (weakly) define respective symbols.

crt*.o from atpacks has these symbols defined, so it makes a difference which crt you are using. See avr-nm crt*.o | grep REGION .

For the time being, you can define the symbols on the command line, e.g. -Wl,--defsym,__TEXT_REGION_LENGTH=64k or in the device-specs file, for example:

*link_text_start:
        --defsym __TEXT_REGION_LENGTH=64k