The current version 7-2018-q2-update of GNU Arm Embedded Toolchain contains arm-none-eabi-ld.bfd, so it does not support Link Time Optimization (LTO).Is there a problem if I try to compile the LTO version? Is the new linker lto hoping to work? Why wasn't it done? Both versions could be distributed, bfd and lto.
best regards
Max
for ld the -flto parameter seems to be ignored:
$ ./arm-none-eabi-ld.bfd --help | grep lto -flto Ignored for GCC LTO option compatibility -flto-partition= Ignored for GCC LTO option compatibility
if I have understood correctly the parameter -flto in compilation makes gcc write in the object file also the bytecode GIMPLE. Then the linker should use the -flto parameter to use the GIMPLE bytecode found in the object files.
reading the documentation of the gcc is not clear to me if it is necessary for the ld to have support for the plugins, and how to use them.
However, there is some reference to lto in the directory tree:
$ find | grep lto./share/doc/gcc-arm-none-eabi/man/man1/arm-none-eabi-dlltool.1./share/doc/gcc-arm-none-eabi/html/binutils.html/dlltool.html./arm-none-eabi/include/c++/7.2.1/ext/pb_ds/detail/cond_dealtor.hpp./arm-none-eabi/include/c++/7.2.1/ext/pb_ds/detail/cc_hash_table_map_/cond_key_dtor_entry_dealtor.hpp./lib/gcc/arm-none-eabi/7.2.1/liblto_plugin.so.0.0.0./lib/gcc/arm-none-eabi/7.2.1/plugin/include/lto-compress.h./lib/gcc/arm-none-eabi/7.2.1/plugin/include/lto-section-names.h./lib/gcc/arm-none-eabi/7.2.1/plugin/include/lto-streamer.h./lib/gcc/arm-none-eabi/7.2.1/liblto_plugin.so.0./lib/gcc/arm-none-eabi/7.2.1/lto1./lib/gcc/arm-none-eabi/7.2.1/lto-wrapper./lib/gcc/arm-none-eabi/7.2.1/liblto_plugin.so
Hi,-flto when linking needs to be passed to GCC, no ld. GCC with then invoke ld with special option to run the LTO plugin. So in your link command line replace ld by gcc (and translate ld specific options to use "-Wl," switch). This will allow you to link successfully an application compiled with LTO.
Best regards.
flto has no effect on ld. It is a gcc option. If you print out the -v when you do
$ ./arm-none-eabi-gcc -O2 -flto -specs=rdimon.specs foo.c -v --save-temps
You will see that the collect2 wrapper invokes the liblto_plugin.so which then reads all the GIMPLE bytecode, invokes lto1 which then subsequently calls the compiler-proper(via the driver) for all the gimple optimization and eventually you have the binary output.
I would encourage you to have a look at the -v output if you want to go deeper into how the lto call sequence works. --save-temps will give you all the intermediate files generated.