Optiboot doesn't fit in 512 bytes when compiled with Toolchain 4 (Avr-gcc v15.x)

[WestfW]

Microchip has released a new "official" avr-gcc toolchain, based on avr-gcc v15.
The normal atmega328p optiboot grows by about 20 bytes, causing it to no longer fit in the 512byte boot sector we want to use.

[dimich-dmb]

The issue seems gone with avr-gcc 16.1.0.
I compiled with -DBAUD_RATE=115200 -DLED_START_FLASHES=2, got .text section even 2 bytes smaller than with avr-gcc 7.3.0.

[sprintersb]

grows by about 20 bytes

If there were build instructions for a specific configuration (like ATmega2560) and no dependencies on fancy (like IDEs or Studio), I could have a look.

[sprintersb]

...so I went to optiboot/bootloaders/optiboot and

$ make -f Makefile.mega0 CC=avr-gcc-15 OPTIMIZE='-Os -fsplit-wide-types'
...
make -f Makefile.mega0 optiboot_attiny1607.hex UARTTX=B2 TIMEOUT=8 LED=B7 LED_INVERT=1
avr-gcc-15 -g -Wall -Os -fsplit-wide-types  -DWDTTIME=8  -DLED_START_FLASHES=3  -DLED=B7  -DLED_INVERT=1 -DUARTTX=B2 -DBAUD_RATE=115200           -Wl,-section-start=.text=0 -Wl,--section-start=.application=0x200 -Wl,--section-start=.version=0x1fe -Wl,--relax -nostartfiles -nostdlib  -mmcu=attiny1607 -o optiboot_attiny1607.elf optiboot_x.c
Bootloader size with skeleton App
   text	   data	    bss	    dec	    hex	filename
    536	      9	      0	    545	    221	optiboot_attiny1607.elf
avr-objdump -S  optiboot_attiny1607.elf > optiboot_attiny1607.lst
avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex optiboot_attiny1607.elf optiboot_attiny1607.hex
Bare Bootloader size
avr-size optiboot_attiny1607.hex
   text	   data	    bss	    dec	    hex	filename
      0	    498	      0	    498	    1f2	optiboot_attiny1607.hex

so it seems all you have to do is providing specific gcc versions with specific extra options?

BTW: Is there a way to build outside of source tree, so I don't clutter up the sources?

[WestfW]

Huh. The "-fno-split-wide-types" option appears to be historical (pre-dates MY involvement), and I don't know why it's there.

Is there a way to build outside of source tree, so I don't clutter up the sources?

No, not currently. Back when there were fewer tagets, (all of) the .hex and .lst files were commited files, but that didn't scale.

[sprintersb]

-f[no-]split-wide-types

There is no recommendation of which is better. A generic solution would be to supply sets of optional switches, and build the loader for all of them. Then chose the smallest binary. Or at least discard builds that fail. Though that may be tricky in a Makefile alone; this is more conveniently done in a script.

In GCC 17, it's again -fno-split-wide-types that wins with 478 bytes vs. 506.

Some more notes on the code:

• All the asms in the code have a trailing \n, like in __asm__ __volatile__ (" wdr\n"). GCC computes the length of an asm as the number of lines multiplied by 4 (the max insns length in bytes). Asm lengths are needed to compute jump offsets for jumps that are acossing the asm.

  So it assigns 8 bytes to the asm above which is a waste because the compiler my use code for a wider jump offset than actually needed. Just remove the trailing \n's. GCC will add trailing line breaks in the asm it generates, so the .s files are legible.

• There is a free floating asm volatile ("clr __zero_reg__") in main. That's no good. Instead, add it at the end of pre_main.

• Referencing optiboot_version would rather be something like:
  asm (".global %0" :: "i" (&optiboot_version))