This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -ffunction-sections and -fdata-sections documentation


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.

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 :-)



Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]