1

Avr-gcc 7.1, Win10.

When compiling a simple LED blinker C code using avr-gcc, it outputs:

avr-gcc output screenshot

Invoking the avr-gcc is done by hand using:

avr-gcc -g -Os -mmcu=attiny13a -c "Attiny_blink_01.c"
avr-gcc -g -mmcu=attiny13a -o "Attiny_blink_01.elf" "Attiny_blink_01.o"
avr-objcopy -j .text -j .data -O ihex "Attiny_blink_01.elf" "Attiny_blink_01.hex"
avr-size --format=avr --mcu=attiny13a "Attiny_blink_01.elf"

Why does AVR-GCC indicate that there is a "bootloader"? Does it "add" something to the code at compile time besides the blinker?

Improve this question
7
  • because it is in your linker script Commented Jun 16 at 9:51
  • 1
    It would seem that whoever wrote these diagnostics were confused, since .data is present twice and they probably meant .rodata or similar in the first case. Commented Jun 16 at 10:48
  • @0___________ "because it is in your linker scrip": No, it isnt. .bootloader is orphan. Commented Jun 16 at 10:57
  • @Lundin - no he ws not confused. .data is present both in FLASH (as startup code needs to take the inial data from somewhere) and RAM . So it is 100% correct. .rodata is not very useful for this target as you need to use special instructions to read data from FLASH. Commented Jun 16 at 11:03
  • @Lundin: Nope. .data occurs twice since it occupies RAM (obviously) and also flash (since the startup code has to initialize static storage from non-volatile memory, which is flash). The .rodata input sections are treated like .data, at least this is the case for classic AVR devices like ATtiny13. Only for the avrxmega2_flmap and avrxmega4_flmap emulations there is a .rodata output section, see for example sourceware.org/PR31124 Commented Jun 16 at 11:04

1 Answer 1

Reset to default
2

Why does AVR-GCC indicate that there is a "bootloader"?

It doesn't. What it shows is the cumulated memory consumption of these three sections. So when there is no bootloader, then the contribution of the .bootloader section is zero.

The mentioned output sections all contribute to the consumed flash size, and therfore when you are interested in the consumed flash size, all mentioned sections have to be considered.

Apart from that, the output is from avr-size and not form the compiler.

For a documentation of memory sections, see for example https://avrdudes.github.io/avr-libc/avr-libc-user-manual/mem_sections.html

Contrary to what has been claimed in a comment, .bootloader is not part of the default linker scripts. When there is code in this section, it will be treated like an orphan section.

avr-size is showing .bootloader because it is hard coded knowledge in avr-size.

Also notice that the used options for avr-size like --mcu are from a private patch that never made it into the official Binutils code base. When you want to display usage of statically allocated memory, you can use the official

$ avr-objdump -P mem-usage <elf-file>

instead.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thanks! I've had a feeling that the .bootloader might be there as a "formality" to show that the output includes all the mem sections. Though what does " used options for avr-size are from a private patch that never made it into the official Binutils code base" refer to in your question? is it about the --format and --mcu args from the avr-size?
I mean --mcu. And --format is documented like this: -A|-B|-G --format={sysv|berkeley|gnu} Select output style (default is berkeley).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.