----- Am 13. Okt 2017 um 16:11 schrieb Jeff Law l...@redhat.com: > On 10/13/2017 01:06 AM, Sebastian Huber wrote: >> Hello, >> >> I would like to update the documentation of these compiler flags and >> have some questions. The -ffunction-sections and -fdata-sections >> documentation is currently: >> >> "Place each function or data item into its own section in the output >> file if the target supports arbitrary sections. The name of the function >> or the name of the data item determines the section’s name in the output >> file. >> >> Use these options on systems where the linker can perform optimizations >> to improve locality of reference in the instruction space. Most systems >> using the ELF object format and SPARC processors running Solaris 2 have >> linkers with such optimizations. AIX may have these optimizations in the >> future. >> >> Only use these options when there are significant benefits from doing >> so. When you specify these options, the assembler and linker create >> larger object and executable files and are also slower. You cannot use >> |gprof| on all systems if you specify this option, and you may have >> problems with debugging if you specify both this option and -g." >> >> The end-of-life of Solaris 2.6 was 2006. Is it worth to mention this here? >> >> This "AIX may have these optimizations in the future." is there since at >> least 1996. What is the current AIX status? >> >> Is the "Only use these options when there are significant benefits from >> doing so. When you specify these options, the assembler and linker >> create larger object and executable files and are also slower. You >> cannot use |gprof| on all systems if you specify this option, and you >> may have problems with debugging if you specify both this option and >> -g." still correct on the systems of today? >> >> Do these options affect the code generation? > They can affect code generation. By placing each object into its own > section it's no longer viable to use one object to refer to another > because the relative addresses are unknown until link time. Without > those options the assembler can compute the offset between two objects > within a given section when they come from the same translation unit.
Is this similar to moving all distinct objects into one compiler generated structure? > > While such tricks aren't valid C code, the compiler and assembler can > work together under the hood to perform these kinds of optimizations. > > The documentation is clearly dated. A patch to update it would be > greatly appreciated :-) I will try to update it.
