What Is the Comdat Section Used For

COMDAT section name

According to the Microsoft PE and COFF Specification, section 4.5.6 (which I'm sure you have read closely if you're writing a linker), the sym= value is the COMDAT symbol, which is used by the linker in conjunction with the Selection value to determine which copy of the COMDAT section to keep in the final image. There are two entries in the symbol table for each COMDAT section. The first has the section name and an auxiliary record with the Selection info. The COMDAT symbol value comes from the second entry in the symbol table for the COMDAT section. It's either the symbol's ShortName value or the value of the string table entry it points to.

The COMDAT symbol value should be identical for all copies of the same COMDAT in the various object files to be linked. There should only be two symbol table entries with the matching SectionNumber for a particular COMDAT section in any one object file, if I understand the spec correctly. You shouldn't see multiple COMDAT symbol strings with different values as symbol table entries for a single COMDAT.

COMDAT section placement in the executable

If you have Edit & Continue turned on for the project, the padding you're seeing is introduced so the compiler and linker can patch the executable image rather than having to rebuild and relink it.

What is a 'linkonce' section

https://gcc.gnu.org/legacy-ml/gcc/2003-09/msg00984.html seems to discuss this very thing.

According to that thread, COMDAT is a bit more nebulous in the sense that there's no single correct/standard definition of what constitutes a true COMDAT implementation. g++'s linkonce is /an/ implementation of the concept.

In the COMDAT implementations used by MSVC++ and Wind River's 'diab' compiler, their implementations of COMDAT allow it to remove unused sections; eg, if main.cpp links against foo.cpp, the main binary can exclude any COMDAT sections from foo.o if the section is not referenced.

I'm uncertain whether this type of folding is applied to the g++ linkonce sections, but it seems logical.

Relation between MSVC Compiler & linker option for COMDAT folding

Answer from someone who communicated with me off-line. Helped me understand these options a lot better.

===================================

That is essentially true. Suppose we talk just C, or C++ but with no member functions. Without /Gy, the compiler creates object files that are in some sense irreducible. If the linker wants just one function from the object, it gets them all. This is specially a consideration in programming for libraries, such that if you mean to be kind to the library's users, you should write your library as lots of small object files, typically one non-static function per object, so that the user of the library doesn't bloat from having to carry code that actually never executes.

With /Gy, the compiler creates object files that have COMDATs. Each function is in its own COMDAT, which is to some extent a mini-object. If the linker wants just one function from the object, it can pick out just that one. The linker's /OPT switch gives you some control over what the linker does with this selectivity - but without /Gy there's nothing to select.

Or very little. It's at least conceivable that the linker could, for instance, fold functions that are each the whole of the code in an object file and happen to have identical code. It's certainly conceivable that the linker could eliminate a whole object file that contains nothing that's referenced. After all, it does this with object files in libraries. The rule in practice, however, used to be that if you add a non-COMDAT object file to the linker's command line, then you're saying you want that in the binary even if unreferenced. The difference between what's conceivable and what's done is typically huge.

Best, then, to stick with the quick answer. The linker options benefit from being able to separate functions (and variables) from inside each object file, but the separation depends on the code and data to have been organised into COMDATs, which is the compiler's work.

===================================

main.obj : fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x6

As pointed out by @RichardCritten,

the files should be compiled with MSVC as the object formats are
tool-chain specific. LNK1143 is from the MS linker and it can't
understand the format of the obj files produced by the other
tool-chain.

So object files created by MinGW's g++ can't be linked with a cuda program's object file with MSVC