[PATCH] [PECOFF] Fill size field of IMAGE_DATA_DIRECTORY

[Richard]

================
Comment at: Atoms.h:256
@@ +255,3 @@
+    std::vector<uint8_t> data = std::vector<uint8_t>(8, 0);
+    *(reinterpret_cast<uint32_t *>(&data[4])) = entrySize;
+    return data;
----------------
entrySize is uint64_t, but you're storing through a uint32_t pointer?

================
Comment at: Atoms.h:255-257
@@ +254,5 @@
+  std::vector<uint8_t> assembleRawContent(uint64_t entrySize) {
+    std::vector<uint8_t> data = std::vector<uint8_t>(8, 0);
+    *(reinterpret_cast<uint32_t *>(&data[4])) = entrySize;
+    return data;
+  }
----------------
Seems like elsewhere in the COFF code I've been reviewing lately we have similar noisy expressions where we desire a vector of bytes and have to jam in binary data.  Can we get a generic binary blob builder that prevents us from having to write these same kinds of expressions across the different COFF code?  Maybe even such a thing is useful to more than just COFF output files?

Come to think of it, I'm not even sure this code will generate a proper COFF executable on a machine that doesn't have the same byte order as an x86 machine.  Won't this break our ability to cross-compile?


http://llvm-reviews.chandlerc.com/D1228