Additional sections introduced when compiling with Optimizations

[Orfeas_Z_]

I'm currently working on a Windows application, developed in C++ using Visual Studio and the Intel C++ 15.1 compiler.

It would appear that when I compile with any kind of optimizations, a few additional sections appear in the output executable, increasing the size of it by a significant margin, and possibly introducing information that I would otherwise not rather have in a release build.

Here's an outline of the different optimization options and the section they generate from an empty test application I made which simply prints to the console:

Optimization: Disabled (/Od)

        2000 .data
        3000 .data1
        2000 .rdata
        1000 .reloc
       12000 .text

Optimization: Minimize Size (/O1)

        3000 .data
        2000 .data1
        3000 .rdata
        1000 .reloc
        A000 .text
        1000 .text1
        1000 _RDATA

Optimization: Maximize Speed (/O2) or Full Optimization (/Ox) or Highest Optimizations (/O3)

        3000 .data
        3000 .data1
        1000 .debug_o
        3000 .rdata
        2000 .reloc
        E000 .text
        1000 .text1
        1000 _RDATA

I was unable to find any information in regards to those sections in the documentation, so any information as to what their purpose is and whether they can be removed would be greatly appreciated.

Thanks in advance.

[Orfeas_Z_]

It should also be noted that this appears to happen when using STL libraries.

[pbkenned1]

Windows object file (COFF, PE) sections/formats are defined by Microsoft and you won't find them described in Intel compiler documents.  The compiler has no control over what sections are generated nor how they are combined to form a finished binary.  I doubt you can remove any of those sections and expect the linker to produce a correct executable.

Patrick

[Orfeas_Z_]

Thank you for your response Patrick, however it would appear that some of these sections contain Intel-specific code.

Sections like .text1 and .data1 appear to contain optimized versions of some core functions (like memcpy), which is totally fine since I can instruct the linker to merge them into a single .text and .data section respectively (it should be noted that I'm compiling with the /MT flag).

What really concerns me is the .debug_o and .trace sections (.trace doesn't appear on the logs I submitted, but appears in my main project binary even with /notraceback specified).

The .debug_o section (which normally is called .debug_opt_report but is trimmed) appears to hold some metadata on optimized functions from my binary, along with instances of the following strings: 

• .itt_notify_tab
• optimization_report_version
• optimization_report

Going through that metadata, one could possibly more easily reverse engineer certain aspects of my application, something that I would most definitely like to prevent.

The .trace section appears to also contain optimization metadata, but mostly for SSE and arithmetic related optimizations.
The paths of some Intel source files are references, such as d:\users\nbtester\x86win_nightly\branch-15_0\20141024_000000\libdev\libm\real\sincosf_sse2.c.

With that being said, the data in these sections is not being referenced from anywhere in any other section, and 'manually' removing them and rebuilding the PE table of the binary appears to have no effect to the application itself.

[pbkenned1]

Thanks for the details regarding the 'metadata' appearing in certain sections.  Indeed some of that exposes sensitive data and if not needed, I think we should clean it up.  Can you attach a small test case that demonstrates the issues?  I'll ask the developers if this is something they can address. 

Thanks,

Patrick

[Orfeas_Z_]

Would you like me to attach a compiled binary, the source/project files for that binary, or both?

[pbkenned1]

Hi Orfeas,

All I need is the source/project files.

Thanks,

Patrick

[Orfeas_Z_]

Hey Patrick,

Attached you will find a zip archive containing a really simple test project with some sample SSE code which produces the aforementioned sections. The project has been set to compile with the Intel C++ 15.0 compiler using the vc120 toolset.

Feel free to let me know if you need any additional information.

Thanks.

[pbkenned1]

Hey Orfeas,

Thanks for attaching your project.  I'll let you know what I find out.

Patrick

[pbkenned1]

The icl generated executable is about 25% larger compared to cl for this simple test case.  I filed a feature request with the developers asking if any of the SECTIONS can be cleaned up or removed altogether without affecting functionality, tracking ID DPD200365224.  I'll keep this thread updated with any news.

Patrick

[Orfeas_Z_]

Thanks Patrick.
I really appreciate your interest and help.

[pbkenned1]

The .debug_o and .trace sections have to be handled separately, so a new problem report (DPD200365543) was created to address the
.trace section issue. 
 
The original problem report (DPD200365224) has been closed as 'will not fix', with the following explanation:
The  .debug_opt_report  is considered an essential part of the debug information and is turned on when a symbolic debugging option
is provided (/Zi) along with an optimization level (/O1, /O2, or /O3).

The compiler provides an option to unconditionally turn off embedded optimization report data:

/Qopt-report-embed-

If option /Zi is specified, special loop information annotations will be embedded in the assembly file and/or object file unless
option /Qopt-report-embed- is specified.

So, for suppressing .debug_opt_report section generation there are two possible solutions:

1) remove symbolic debugging option (/Zi)  from options set when compiling source files for release.
2) Add /Qopt-report-embed- option to options set

Regarding the .trace section issue:
By default icl does not produce traceback information for any user source (unless explicitly requested).
Users might see a .trace segment in their executable when they linked against Intel provided libraries which are shared between Fortran
and C/C++ compilers.  It can be seen that the .trace section data referenced an Intel library source file for the math lib (libm).

The developer was not able to find a way to omit traceback related data when linking the executable. MSFT seems have no tools to strip
a segment from an object (editbin.exe seems have no such functionality), and we're not aware of any tool that can strip a section from
an object or executable file on Windows. MSFT LINK tool also does not list any option to omit linking of a specific section.

Having said all that, DPD200365543 remains open to address anything that might be done to clean up the .trace section.

Patrick

[Orfeas_Z_]

Hello Patrick,

Thank you very much for getting back to me.

It would appear that the /Qopt-report-embed- option does indeed prevent the compiler from embedding optimization information in the PE output.

As for the .trace section, please keep me up-to-date with any developments.

Thanks.

[pbkenned1]

>>>As for the .trace section, please keep me up-to-date with any developments.

The .trace section has been substantially cleaned up with Intel C++ 16.0 update 2, which is available in the Intel Registration Center.

In particular, references to Intel source files have been removed. 

For example, with the old 15.0 compiler, we have:

RAW DATA #6
  0000000140044000: 0A 02 00 00 AE 00 00 00 00 9E 00 40 01 00 00 00  ....®......@....
  0000000140044010: 01 00 00 00 10 00 00 00 00 00 75 00 44 3A 5C 6C  ..........u.D:\l
  0000000140044020: 61 62 73 65 72 76 65 72 70 72 6F 63 65 73 73 5C  abserverprocess\
  0000000140044030: 65 66 69 32 77 69 6E 5F 63 6C 61 73 73 69 63 49  efi2win_classicI
  0000000140044040: 53 53 5F 31 35 5F 30 5F 32 30 31 35 31 31 32 30  SS_15_0_20151120
  0000000140044050: 5F 30 31 30 30 30 30 5F 31 30 37 33 37 34 39 35  _010000_10737495
  0000000140044060: 33 33 5C 32 30 31 35 31 31 32 30 5F 30 31 30 30  33\20151120_0100
  0000000140044070: 30 30 5C 6C 69 62 64 65 76 5C 6C 69 62 6D 5F 63  00\libdev\libm_c
  0000000140044080: 74 5C 72 65 61 6C 5C 6D 61 74 68 65 72 72 6C 2E  t\real\matherrl.
  0000000140044090: 63 00 00 00 00 00 00 00 0C 00 08 00 00 9E 00 40  c..............@

With the 16.0.2 compiler, you won't see any of that.

Patrick