COMDAT and Duplicate Sections

The Actual Detail

The source that produces the situation naturally:

struct S { int a, b; };
inline S make(int v) { S s; s.a = v; s.b = v * 2; return s; }
int f() { S s = make(3); return s.a + s.b; }
template<class T> T twice(T v) { return v + v; }
int g() { return twice(21); }

Compile it and count the sections:

$ clang++ --target=x86_64-pc-windows-msvc -c comdat.cpp -o comdat.obj
$ file comdat.obj
comdat.obj: x86-64 COFF object file, not stripped, 13 sections
$ llvm-objdump -h comdat.obj | head -18

Thirteen sections, and .text appears three times. So does .xdata, and so does .pdata. Duplicate section names are perfectly legal in COFF — they are not a bug and not even unusual — and they are how COMDAT works:

The COMDAT sections are the ones whose characteristics differ from their non-COMDAT namesake by exactly the 0x1000 bit. Compare section 4 and section 10, both .xdata:

plain  .xdata:  40 00 30 40     0x40300040
COMDAT .xdata:  40 00 10 40     0x40301040
                              ^^^^^
                     0x1000 = IMAGE_SCN_LNK_COMDAT

The selection policies

Now the part that is not a flag. The Selection byte at offset 0x0e of the section's aux record tells the linker which duplicate to keep, and both values below occur naturally in this one object:

ANY is the one you will see most: the compiler has decided the bodies are equivalent, so the linker may keep whichever copy it likes. ASSOCIATIVE is subtler and more interesting, because the decision is not about this section at all — it is about a group.

Here is the pairing, straight from the aux records. The .pdata COMDAT (section 12) has Length 12, Selection 5, Number 5, and the .xdata COMDAT that shares its Number (section 10) has Length 8, Selection 5, Number 5. The Number field is the group identifier. Two sections with the same number and Selection = ASSOCIATIVE are a unit: the linker keeps them together or discards them together.

Why does that matter? Because an .xdata entry without its matching .pdata entry, or the reverse, is meaningless. A .pdata record says "this range of code unwinds using the unwind data at this address". Keep one half and the exception unwinder faults at runtime. Neither section is meaningful alone, so neither may be independently discarded — and ASSOCIATIVE is how the format says that.

And the CheckSum is what makes the decision safe. The verified values from this object:

Note that sections 5 and 6 have different checksums. They are both named .text, both marked COMDAT, and both use ANY — but they are not the same bytes. That is correct and expected: they are two different functions, each with its own body, and the compiler emitted each in its own COMDAT section. The checksum is not what makes them duplicates; the symbol names do. Two COMDAT sections with the same name and the same checksum coming from two different object files are the same function, and one is discarded.