[LLD][COFF] Deduplicate .pdata entries

[aganea]

Summary

When targetting x64, before this patch LLD would generate duplicate RUNTIME_FUNCTION entries. They are not exactly duplicates stricto sensu, because the unwind RVA is different. However the two target UNWIND_INFOs would have the same content. An example out of the final EXE before this patch (I used dumpbin /unwindinfo ...):

0049D0DC 0554E9D0 0554E9F7 06ACBCE8   <- RUNTIME_FUNCTION entry (in .pdata)
   Unwind version: 1                  <- pointed UNWIND_INFO entry (in .xdata)
   Unwind flags: EHANDLER UHANDLER
   Size of prologue: 0x0A
   Count of codes: 2
   Unwind codes:
     0A: ALLOC_SMALL, size=0x30
     06: PUSH_NONVOL, register=rbp
   Handler: 05503340 
0049D0E8 0554E9D0 0554E9F7 06ACB0E8   <- note the last value (the unwind RVA) is different
   Unwind version: 1                  <- different UNWIND_INFO entry, but same content as above
   Unwind flags: EHANDLER UHANDLER
   Size of prologue: 0x0A
   Count of codes: 2
   Unwind codes:
     0A: ALLOC_SMALL, size=0x30
     06: PUSH_NONVOL, register=rbp
   Handler: 05503340

Unfourtunately this prevents us from using some external (commercial) post-processing tools, which assert if the EXE contains duplicate .pdata entries. This behavior is probably wrong anyway, how would the NT loader handle duplicate entries for the same function?

After this patch, we thusly remove any .pdata entries that have the same starting address. We make those changes directly into the final output stream, because the input .pdata streams need to merged, reallocated & sorted first. This has two side-effects: 1. the output PE section that receives the .pdata ends-up a bit larger than needed. 2. the .xdata entries are not stripped currently since they are part of .text sections (same chunks). But all in all we're talking about a few kbytes wasted. In our case, out of 300,000 RUNTIME_FUNCTION entries, this patch removes about 700, so that's about 14 kb wasted out of a 96 MB EXE.

If reviewers would think of a better way to implement this, I would gladly oblige.

Fixes PR45950.

[mstorsjo]

Just curious - do you know why you end up with duplicates? In most cases where there could be duplicates, they should be in a comdat section where only one is picked? And if not, you'd have a duplicate definition of a symbol in the corresponding text section - right?

lld/COFF/Writer.cpp

1869

Would it be possible to adjust the virtual size of the .pdata section as well, to exclude the pruned bits? I could imagine that some runtime introspection tools locate the section directly instead of using the data directory.

[mstorsjo]

In D82883#2126581, @mstorsjo wrote:

Just curious - do you know why you end up with duplicates? In most cases where there could be duplicates, they should be in a comdat section where only one is picked? And if not, you'd have a duplicate definition of a symbol in the corresponding text section - right?

Poking into this again - so in the testcase, you made the .text section a comdat so that doesn't conflict, but not the .pdata/.xdata. As far as I know, when llvm generates .pdata/.xdata for a comdat .text section, the .pdata/.xdata sections also should be comdat (and made associative to the .text section).

So in the case when you're running into this issue, aren't .pdata made into an associative comdat at all? Or does it work in general, but is failing in some corner case? Or is it a case of handwritten assembly, or code generated by some other external tool that doesn't get this aspect entirely right?

[aganea]

@mstorsjo This happens on VS2019 libs. I don't know if this happens on VS2017. I don't have an exact repro, but the test below exhibits the same effect as the problem I was observing. I will dig more into this.

lld/COFF/Writer.cpp

1869

Unfortunately the .pdata is merged into .rdata, there're other things following the merged .pdata in the output, and at this point all the RVAs have been calculated and sections already merged & written.

I've tried pruning earlier, but it's a tail biting snake. We need the entire merged, reallocated & sorted .pdata stream, and the computed RVAs, but we don't have that unless all sections have been written. But once they're written, we can't prune them, unless we would re-write again.

If we did a two-step "writeSection" and perhaps computed everything in advance, before writing, it could maybe be possible to resize the output section, but that would involve some sizeable refactoring. I figured it wasn't worth it, but if anyone has a different view on this, please let me know.

[mstorsjo]

In D82883#2147461, @aganea wrote:

@mstorsjo This happens on VS2019 libs. I don't know if this happens on VS2017. I don't have an exact repro, but the test below exhibits the same effect as the problem I was observing. I will dig more into this.

Right, so in the object file bits that end up linked in statically? Interesting.

What does MSVC link.exe do in that case - does it also dedup them, or keep the duplicates?

lld/COFF/Writer.cpp

1869

Right, I agree it's probably a sensible tradeoff to keep it like this - it's probably not worth rearchitecting things just to be able to prune it better.

To see that I understand the issue correctly: Before we've fixed the layout and set RVAs, the .pdata section is unsorted. At that stage, we should still be able to check which pdata entries actually point to the same symbol (although it might be messy, having to dereference the relocations?) - but without sorting it, a duplicate check would end up rather costly - and without RVAs we can't really sort it. Am I understanding the situation correctly?

Given the (presumed) small extent of the issue, this solution does sound like a good tradeoff.

Also, right, if merging .pdata into another section, there's no need to update section sizes (and in that case, a few noop bytes in the middle of the .rdata are just orphaned bytes anyway).

IIRC with mingw setups, .pdata doesn't normally end up merged though. Is it (within reasonable effort) possible to check if .pdata is left unmerged, and in that case fix the section size? Or is the association from the enclosing section lost earlier at some point? If not, then this is clearly good enough.

[aganea]

lld/COFF/Writer.cpp

1869

Yes, the description of the situation is correct. I think all this would potentially wouldn't be a problem if /Gy was used for compiling (which is not the case here), then perhaps de-dup would be done correctly. However even at that I'm not sure, it seems the de-dup in ICF.cpp is done by hashing the chunk content, which doesn't work in the case of .pdata. Even if the realloc was applied and RVA computed, the ICF would still need to understand that two different .pdata records (RUNTIME_FUNCTION) are equal if they point to two different .xdata records (UNWIND_INFO) but with the same content. I've also ran into a peculiar case where two .xdata records were almost the same, bearing the fact they were using a different unwind handler (__CxxFrameHandler4 instead of 3) - however the unwind codes were all the same.

link.exe does seems to merge all .pdata records, because we didn't see this issue with the post-link tool I've mentioned (which asserts if two contigous .pdata records point to the same .text function).

As for the output section size, I'll extend the patch with your suggestion!

[aganea]

I've digged a bit more. The issue is that the ICF improperly folds .text$x sections (catch funclets) but not always the "associated" .pdata and .xdata records, in part because those additional sections are attached to .text$mn not to .text$x. This occurs only with MSVC-cl built OBJs, Clang does not create separate .text$x sections for catch functlets (rather, they are merged into the function .text). I'm seeing the bug when linking with the FBX SDK 2016.1 VS2015 (lib\vs2015\x64\release\libfbxsdk-mt.lib).

The COFF table for fbxmesh.obj in the archive above looks like this:

11C 00000000 SECT88 notype       Static       | .text$mn
    Section length   52, #relocs    2, #linenums    0, checksum 270664C2, selection    2 (pick any)
11E 00000000 SECT89 notype       Static       | .text$x            <<<< ----- this is de-duplicated, probably it shouldn't be ----- >>>>
    Section length   20, #relocs    2, #linenums    0, checksum 7C6EA17D, selection    5 (pick associative Section 0x88)
...
817 00000000 SECT160 notype       Static      | .xdata
    Section length   10, #relocs    2, #linenums    0, checksum DFA6EA80, selection    5 (pick associative Section 0x88)
819 00000000 SECT160 notype       Static      | $unwind$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
81A 00000000 SECT161 notype       Static      | .pdata
    Section length    C, #relocs    3, #linenums    0, checksum 1703F4BB, selection    5 (pick associative Section 0x88)
81C 00000000 SECT161 notype       Static      | $pdata$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
81D 00000000 SECT162 notype       Static      | .rdata
    Section length   28, #relocs    3, #linenums    0, checksum  849A3B3, selection    5 (pick associative Section 0x88)
81F 00000000 SECT162 notype       Static      | $cppxdata$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
820 00000000 SECT163 notype       Static      | .xdata
    Section length   10, #relocs    0, #linenums    0, checksum 8999943C, selection    5 (pick associative Section 0x88)
822 00000000 SECT163 notype       Static      | $stateUnwindMap$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
823 00000000 SECT164 notype       Static      | .xdata
    Section length   14, #relocs    1, #linenums    0, checksum 570F4CF1, selection    5 (pick associative Section 0x88)
825 00000000 SECT164 notype       Static      | $tryMap$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
826 00000000 SECT165 notype       Static      | .xdata
    Section length   14, #relocs    1, #linenums    0, checksum   677058, selection    5 (pick associative Section 0x88)
828 00000000 SECT165 notype       Static      | $handlerMap$0$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
829 00000000 SECT166 notype       Static      | .xdata
    Section length   28, #relocs    5, #linenums    0, checksum F9326582, selection    5 (pick associative Section 0x88)
82B 00000000 SECT166 notype       Static      | $ip2state$?_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ
82C 00000000 SECT167 notype       Static      | .xdata
    Section length   10, #relocs    2, #linenums    0, checksum 5840A276, selection    5 (pick associative Section 0x88)
82E 00000000 SECT167 notype       Static      | $unwind$?catch$0@?0??_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ@4HA
82F 00000000 SECT168 notype       Static      | .pdata            <<<< ----- but this is not de-duplicated ----- >>>>
    Section length    C, #relocs    3, #linenums    0, checksum F9766256, selection    5 (pick associative Section 0x88)
831 00000000 SECT168 notype       Static      | $pdata$?catch$0@?0??_Buyheadnode@?$_Tree_comp_alloc@V?$_Tmap_traits@HHU?$less@H@std@@V?$allocator@U?$pair@$$CBHH@std@@@2@$00@std@@@std@@QEAAPEAU?$_Tree_node@U?$pair@$$CBHH@std@@PEAX@2@XZ@4HA

Note how all associative COMDATs are attached to .text$mn, none to .text$x, this seems to be by design.

This gives this non-trivial graph: https://miro.com/app/board/o9J_klyfWoY=/

In essence, we end up with several .pdata entries in the PE pointing to the same .text$x address.

I think there should be a rule in the ICF to prevent .text$x (SECT89) from being folded if its pointee .xdata and .pdata cannot be folded as well, like here. Although the ICF algorithm seems to work based only on forward dependencies.

I can't find a repro, something else could be involved (the counter for the equivalence classes?).
I've tried the following:

// --- foo.h
void bar(int);
void bar(unsigned);
template <typename T> struct A {
  template <typename X> void foo(X a) {
    try {
      bar(a);
    } catch (...) {
      throw;
    }
  }
};
// --- a.cpp
#include "foo.h"
void test(int a) {
  A<int> val;
  val.foo(a);
}
// --- b.cpp
#include "foo.h"
template <> struct A<unsigned> {
  void foo(unsigned a) {
    try {
      bar(a);
      bar(a);
    } catch (...) {
      throw;
    }
  }
};
void alttest(unsigned a) {
  A<unsigned> val;
  val.foo(a);
}

But that doesn't trigger the bug. The issue seems to be occuring on the MS-STL std::_Tree::_Insert_nohint function, although from MS-STL VS2015.

There are many other libraries linked in, compiled with VS2019 or VS2017, so the issue could be from elsewhere.

I'm a bit stuck at the point. Would you go with the current patch, or something different in lld/COFF/ICF.cpp?
Ideas? @majnemer @rnk @ruiu

[rnk]

This all sounds like this bug: https://bugs.llvm.org/show_bug.cgi?id=35337
Which was supposed to be fixed in rG107f55005bc9c9de2378057f56ae02016795a3ae

As I understand it, we have several catch blocks that are functionally identical (same text), but they have different xdata (EH states), and we probably shouldn't fold them together.

Note how all associative COMDATs are attached to .text$mn, none to .text$x, this seems to be by design.

I see, so that prevents our fix from doing what it's supposed to. However, I notice that all the .text$x sections are associated with the .text$mn section. Is ICF running on the .text$x sections even though they are associated with something else? It probably shouldn't be if it is. That could be the fix.

---

By the way, it would be a great improvement to LLVM to emit funclets in a separate .text$x section. It's a natural way to implement hot/cold code partitioning, it separates code that only runs during EH from non-exceptional code. This is actually one of the few advantages of funclets over landingpads: it's really easy to implement this partitioning.

lld/COFF/Writer.cpp

private:
   void mergeSections();
   void removeUnusedSections();
   void assignAddresses();
   void finalizeAddresses();
   void removeEmptySections();
   void assignOutputSectionIndices();
   void createSymbolAndStringTable();
   void openFile(StringRef outputPath);
-  template <typename PEHeaderTy> void writeHeader();
+  template <typename PEHeaderTy> data_directory *writeHeader();
   void createSEHTable();
   void createRuntimePseudoRelocs();
   void insertCtorDtorSymbols();
   void createGuardCFTables();
   void markSymbolsForRVATable(ObjFile *file,
                               ArrayRef<SectionChunk *> symIdxChunks,
                               SymbolRVASet &tableSymbols);
   void maybeAddRVATable(SymbolRVASet tableSymbols, StringRef tableSym,
                         StringRef countSym);
   void setSectionPermissions();
   void writeSections();
   void writeBuildId();
-  void sortExceptionTable();
+  void sortExceptionTable(data_directory *dir);
   void sortCRTSectionChunks(std::vector<Chunk *> &chunks);
   void addSyntheticIdata();
   void fixPartialSectionChars(StringRef name, uint32_t chars);
   bool fixGnuImportChunks();
   PartialSection *createPartialSection(StringRef name, uint32_t outChars);
   PartialSection *findPartialSection(StringRef name, uint32_t outChars);
 
   llvm::Optional<coff_symbol16> createSymbol(Defined *d);
void Writer::run() {
   setSectionPermissions();
   createSymbolAndStringTable();
 
   if (fileSize > UINT32_MAX)
     fatal("image size (" + Twine(fileSize) + ") " +
         "exceeds maximum allowable size (" + Twine(UINT32_MAX) + ")");
 
   openFile(config->outputFile);
-  if (config->is64()) {
-    writeHeader<pe32plus_header>();
-  } else {
-    writeHeader<pe32_header>();
-  }
+  data_directory *dir = config->is64() ? writeHeader<pe32plus_header>()
+                                       : writeHeader<pe32_header>();
   writeSections();
-  sortExceptionTable();
+  sortExceptionTable(dir);
 
   t1.stop();
 
   if (!config->pdbPath.empty() && config->debug) {
     assert(buildId);
     createPDB(symtab, outputSections, sectionTable, buildId->buildId);
   }
   writeBuildId();
void Writer::assignAddresses() {
   sizeOfImage = alignTo(rva, config->align);
 
   // Assign addresses to sections in MergeChunks.
   for (MergeChunk *mc : MergeChunk::instances)
     if (mc)
       mc->assignSubsectionRVAs();
 }
 
-template <typename PEHeaderTy> void Writer::writeHeader() {
+template <typename PEHeaderTy> data_directory *Writer::writeHeader() {
   // Write DOS header. For backwards compatibility, the first part of a PE/COFF
   // executable consists of an MS-DOS MZ executable. If the executable is run
   // under DOS, that program gets run (usually to just print an error message).
   // When run under Windows, the loader looks at AddressOfNewExeHeader and uses
   // the PE header instead.
   uint8_t *buf = buffer->getBufferStart();
   auto *dos = reinterpret_cast<dos_header *>(buf);
   buf += sizeof(dos_header);
template <typename PEHeaderTy> data_directory *Writer::writeHeader() {
   for (OutputSection *sec : outputSections) {
     sec->writeHeaderTo(buf);
     buf += sizeof(coff_section);
   }
   sectionTable = ArrayRef<uint8_t>(
       buf - outputSections.size() * sizeof(coff_section), buf);
 
   if (outputSymtab.empty() && strtab.empty())
-    return;
+    return dir;
 
   coff->PointerToSymbolTable = pointerToSymbolTable;
   uint32_t numberOfSymbols = outputSymtab.size();
   coff->NumberOfSymbols = numberOfSymbols;
   auto *symbolTable = reinterpret_cast<coff_symbol16 *>(
       buffer->getBufferStart() + coff->PointerToSymbolTable);
   for (size_t i = 0; i != numberOfSymbols; ++i)
     symbolTable[i] = outputSymtab[i];
   // Create the string table, it follows immediately after the symbol table.
   // The first 4 bytes is length including itself.
   buf = reinterpret_cast<uint8_t *>(&symbolTable[numberOfSymbols]);
   write32le(buf, strtab.size() + 4);
   if (!strtab.empty())
     memcpy(buf + 4, strtab.data(), strtab.size());
+  return dir;
 }
 
 void Writer::openFile(StringRef path) {
   buffer = CHECK(
       FileOutputBuffer::create(path, fileSize, FileOutputBuffer::F_executable),
       "failed to open " + path);
 }
 
void Writer::writeBuildId() {
 
   uint8_t *buf = buffer->getBufferStart();
   buf += dosStubSize + sizeof(PEMagic);
   object::coff_file_header *coffHeader =
       reinterpret_cast<coff_file_header *>(buf);
   coffHeader->TimeDateStamp = timestamp;
 }
 
+// Remove duplicate RUNTIME_FUNCTION entries from the exception table.
+template <typename Entry>
+static void pruneExceptionTable(Entry *begin, Entry *end, data_directory *dir) {
+  unsigned removed = 0;
+  for (Entry *e = begin + 1; e < end - removed;) {
+    Entry *prev = e - 1;
+    if (e->begin != prev->begin) {
+      ++e;
+      continue;
+    }
+    // Duplicates seem to be rare, so moving memory around shouldn't occur too
+    // often.
+    memmove(prev, e, (uint8_t *)(end - removed) - (uint8_t *)e);
+    ++removed;
+  }
+  if (removed) {
+    // Zero-out the reminder of the table. It'll consume a bit extra space in
+    // the PE image, but that should be fine.
+    memset(end - removed, 0, removed * sizeof(Entry));
+
+    // Adjust PE's data directory
+    dir[EXCEPTION_TABLE].Size = (uint8_t *)(end - removed) - (uint8_t *)begin;
+
+    if (config->verbose)
+      log("Removed " + Twine(removed) + " duplicate .pdata entries.");
+  }
+}
+
 // Sort .pdata section contents according to PE/COFF spec 5.5.
-void Writer::sortExceptionTable() {
+void Writer::sortExceptionTable(data_directory *dir) {
   if (!firstPdata)
     return;
   // We assume .pdata contains function table entries only.
   auto bufAddr = [&](Chunk *c) {
     OutputSection *os = c->getOutputSection();
     return buffer->getBufferStart() + os->getFileOff() + c->getRVA() -
            os->getRVA();
   };
   uint8_t *begin = bufAddr(firstPdata);
   uint8_t *end = bufAddr(lastPdata) + lastPdata->getSize();
   if (config->machine == AMD64) {
     struct Entry { ulittle32_t begin, end, unwind; };
     parallelSort(
         MutableArrayRef<Entry>((Entry *)begin, (Entry *)end),
         [](const Entry &a, const Entry &b) { return a.begin < b.begin; });
+    pruneExceptionTable((Entry *)begin, (Entry *)end, dir);
     return;
   }
   if (config->machine == ARMNT || config->machine == ARM64) {
     struct Entry { ulittle32_t begin, unwind; };
     parallelSort(
         MutableArrayRef<Entry>((Entry *)begin, (Entry *)end),
         [](const Entry &a, const Entry &b) { return a.begin < b.begin; });
+    pruneExceptionTable((Entry *)begin, (Entry *)end, dir);
     return;
   }
   lld::errs() << "warning: don't know how to handle .pdata.\n";
 }
 
 // The CRT section contains, among other things, the array of function
 // pointers that initialize every global variable that is not trivially
 // constructed. The CRT calls them one after the other prior to invoking

lld/test/COFF/unwind.test

 # RUN: yaml2obj < %s > %t.obj
+# RUN: yaml2obj < %s > %t2.obj
 #
 # RUN: lld-link /out:%t.exe /entry:main %t.obj
 # RUN: llvm-readobj --file-headers %t.exe | FileCheck -check-prefix=HEADER %s
 # RUN: llvm-objdump --unwind-info %t.exe | FileCheck --check-prefix=UNWIND %s
 #
-# RUN: lld-link /merge:.pdata=.rdata /out:%t.exe /entry:main %t.obj
+# RUN: lld-link /merge:.pdata=.rdata /out:%t.exe /entry:main %t.obj %t2.obj
 # RUN: llvm-readobj --file-headers --sections %t.exe | FileCheck -check-prefix=HEADER-MERGE %s
 #
 # HEADER: ExceptionTableRVA: 0x3000
 #
 # FIXME: llvm-readobj currently does not understand files with .pdata merged
 # into .rdata. But we can at least check that the section headers look correct.
 #
-# HEADER-MERGE: ExceptionTableRVA: 0x2004
+# HEADER-MERGE: ExceptionTableRVA: 0x2008
 # HEADER-MERGE-NEXT: ExceptionTableSize: 0x30
 # HEADER-MERGE: Name: .rdata
-# HEADER-MERGE-NEXT: VirtualSize: 0x78
+# HEADER-MERGE-NEXT: VirtualSize: 0xF0
 # HEADER-MERGE-NEXT: VirtualAddress: 0x2000
 #
 # UNWIND: Function Table:
 # UNWIND:   Start Address: 0x1000
 # UNWIND:   End Address: 0x101b
 # UNWIND:   Unwind Info Address: 0x2004
 # UNWIND:     Version: 1
 # UNWIND:     Flags: 1 UNW_ExceptionHandler

 # UNWIND:       0x00: UOP_PushMachFrame w/o error code
 
 --- !COFF
 header:
   Machine:         IMAGE_FILE_MACHINE_AMD64
   Characteristics: [  ]
 sections:
   - Name:            .text
-    Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
+    Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_LNK_COMDAT, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
     Alignment:       4
     SectionData:     4883EC184889742410440F110424534889E3488D235B4883C418C3C34881ECF0FF00004881ECF0FF80004881C4F0FF80004881C4F0FF0000C3
   - Name:            .xdata
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
     Alignment:       4
     SectionData:     0912080312030F300E880000096402000422001A000000000000000021000000000000001B000000000000000100000000000000010E06000E11F0FF80000701FE1F001A
     Relocations:
       - VirtualAddress:  20
- Name:            .text
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
       Length:          57
       NumberOfRelocations: 0
       NumberOfLinenumbers: 0
       CheckSum:        0
       Number:          1
+      Selection:       IMAGE_COMDAT_SELECT_ANY
   - Name:            .xdata
     Value:           0
     SectionNumber:   2
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
       Length:          68