-ffunction-sections and -fdata-sections documentation

[Sebastian Huber]

----- Am 13. Okt 2017 um 16:11 schrieb Jeff Law law@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.