HoodLoader2
HoodLoader2 copied to clipboard
NicoHood
Doesn't compile with avrgcc 10.3.0 in Arch GNU/Linux
Compiling Hoodloader2 with avrgcc version 10.3.0 results in the error: make [INFO] : Begin compilation of project "HoodLoader2"... avr-gcc (GCC) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [LNK] : Linking object files into "HoodLoader2.elf" avr-gcc obj/HoodLoader2.o obj/Descriptors.o obj/BootloaderAPI.o obj/BootloaderAPITable.o obj/HID> /usr/bin/avr-ld: section .apitable_trampolines LMA [0000000000003fa0,0000000000003fb7] overlaps > collect2: error: ld returned 1 exit status make: *** [../lufa/LUFA/Build/DMBS/DMBS/gcc.mk:251: HoodLoader2.elf] Fehler 1
Yes I know, the size is too large. And I have no clue what was changed in the last versions. Maybe we can improve by enabling a magic compiler switch I do not know yet :-/
@anatol can you maybe help here? Do you know of any major gcc change that causes bootloaders to compile with larger sizes?
I do not know what change can affect it.
But let's see what can be found here. Is the problem that apitable_trampolines section grew over some limit? Does apitable_trampolines section come from https://github.com/NicoHood/HoodLoader2/blob/master/avr/bootloaders/DFU/BootloaderAPITable.S ?
If yes then I wonder if jmp or ret instruction size has changed e.g. due to changed memory model (e.g. was a relative jump became a long jump). @Virtual-Java could you please provide a disassembled section content for apitable_trampolines before and after the compiler change.
Also I am about to push avr-gcc 11.1 to arch testing. You might want to test that compiler version just in case.
It seams that gcc-5.4 and gcc-10.3 produce almost the same output. The only difference is that gcc-5.4 compiles with success while gcc-10.3 ends with linking errors. To analyze the differences between the files created by gcc I used Githubs compare function: https://github.com/Virtual-Java/HoodLoader2/tree/arch-gcc10-error https://github.com/Virtual-Java/HoodLoader2/tree/mint-gcc5
Edit (by nicohood): https://github.com/Virtual-Java/HoodLoader2/compare/mint-gcc5...Virtual-Java:arch-gcc10-error
I want to note, that this error happens when the size is larger than those defined 4kb. You can edit the makefile and set it to 5kb and it will compile fine. However the bootloader will of course not work. I thought that the original reason was that the newer gcc produces are larger output binary which breaks the linking afterwards.
Looking at the map file I can see more debug entries. But I have no idea if that is relevant: https://github.com/Virtual-Java/HoodLoader2/compare/mint-gcc5...Virtual-Java:arch-gcc10-error#diff-c2f34ddeeacd7bc82bf1c5be8107e0e4c134735ba8d66f5913b9588660961224R23-R104
Sorry for my prediction there is no difference between the output of the two gcc versions. However it was an error due to cloning the repository together with the complete output from the compilation before with gcc-5.4. When you compile with gcc and the object and .elf files already exist from the previous compilation (with the older gcc version), gcc prints out a message that makes you believe compilation succeeded but it didn't. You can get rid of the output from previous compilation by deleting the objects directory and the .elf file. In fact there are significant differences! Comparing the .lss files it's conspicuous that the text section has more content now (f5e vs. 100a) and there is no trampoline_end section anymore. https://github.com/Virtual-Java/HoodLoader2/compare/mint-gcc5...Virtual-Java:virtual-5kB-bootsize-test#
After multiple tries in vain with different optimization options and avr-gcc-12.0.1, I decided to create a package using the gcc-version offered for download by microchip. You can find my package that solved this flash issue for me in the aur.
However getting the pkgbuilt to compile with recent gcc-versions was a lot of work. Compile sizes are now the same as in debian based distros that optain avr-gcc-atmel-5.4.0 by utilizing apt.
Since I don't have the permissions to maintain the repository owned by another maintainer in the aur, I temporarily created a fork that contains my changes on github. How can I get the maintainer of such an package in the AUR marked as orphan?
You have opened a merge request, but you rather want to orphan it. I am a trusted user, so I did that for you. You can now take ownership over the package and push your changes. Sounds like a good plan.
I guess you have spend tons of time in research why it does not work. I am still wondering why this is so difficult. That is really a pity, as when gcc versions move on, we will no longer be able to compile this package. This is somehow a downgrade from older versions, which should not happen. Can't we open a bug report at the gcc compiler? Maybe the guys there know it better?