[John Thacker <johnthacker@xxxxxxxxx>]

We have already been enabling /bigobj when ASan is enabled.

   ( https://gitlab.com/wireshark/wireshark/-/commit/be4ea87bb63c53fa76a3d829a5951ee5e745f0f3 )

 

It's probably not a big deal to enable it always. It makes the object files a little larger (2% in an average case) and makes pre-Visual Studio 2005 linkers not work with the object files.

There's been an open request to Microsoft on their development site to make /bigobj the default for five years: 

     https://developercommunity.visualstudio.com/t/Enable-bigobj-by-default/1031214

John

On Thu, Jul 3, 2025 at 7:28 PM Guy Harris <gharris@xxxxxxxxx> wrote:

On Jul 3, 2025, at 2:33 PM, Maynard, Chris via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

I’m experiencing another Wireshark build failure due to:

 

         C:\Wireshark\src\master\epan\dissectors\packet-nr-rrc.c(1,1): error C1128

       : number of sections exceeded object file format limit: compile with /bigob

       j [C:\Wireshark\builds\x64\master\epan\dissectors\dissectors.vcxproj]

         cl : command line  error D8040: error creating or communicating with chil

       d process [C:\Wireshark\builds\x64\master\epan\dissectors\dissectors.vcxpro

       j]

 

I’m using Visual Studio v17.14.7 (MSVC 19.44.35211.0) in case that matters, because this is different than what the builder is using (i.e., MSVC 19.41.34123.0), and that one is successful.

https://learn.microsoft.com/en-us/cpp/build/reference/bigobj-increase-number-of-sections-in-dot-obj-file?view=msvc-170

"By default, an object file can hold up to 65,279 (almost 2^16) addressable sections. This limit applies no matter which target platform is specified. /bigobj increases that address capacity to 4,294,967,296 (2^32).

Most modules never generate an .obj file that contains more than 65,279 sections. However, machine-generated code, or code that makes heavy use of template libraries, may require .obj files that can hold more sections. /bigobj is enabled by default on Universal Windows Platform (UWP) projects because the machine-generated XAML code includes a large number of headers. If you disable this option on a UWP app project, your code may generate compiler error C1128.

For information on the PE-COFF object file format, see PE Format in the Windows documentation."

"PE Format" at https://learn.microsoft.com/en-us/windows/win32/debug/pe-format says:

section The basic unit of code or data within a PE or COFF file. For example, all code in an object file can be combined within a single section or (depending on compiler behavior) each function can occupy its own section. With more sections, there is more file overhead, but the linker is able to link in code more selectively. A section is similar to a segment in Intel 8086 architecture. All the raw data in a section must be loaded contiguously. In addition, an image file can contain a number of sections, such as .tls or .reloc , which have special purposes.

OK, yeah, epan/dissectors/packet-nr-rrc.c is generated by asn2wrs, but it only has 48 functions; perhaps one of the header files does something that creates > 65,279 sections.

https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/fatal-error-c1128?view=msvc-170

says

Reaching this section limitation can be the result of using /Gy and a debug build; /Gy causes functions to go into their own COMDAT sections. In a debug build, there is a debug info section for each COMDAT function.

C1128 can also be caused when there are too many inline functions.

It sounds as if the main problem with enabling /bigobj is that it may break the ability to have your object code linked with pre-Visual Studio 2005(!) linkers.

I don't think that's an issue for us.

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx