[PATCH] [PECOFF] Fill size field of IMAGE_DATA_DIRECTORY

[Rui Ueyama]

================
Comment at: WriterPECOFF.cpp:385
@@ -384,3 +384,3 @@
   void setBaseRelocField(uint32_t addr, uint32_t size) {
-    auto *atom = new (_alloc) coff::COFFDataDirectoryAtom(_file, 5);
+    auto *atom = new (_alloc) coff::COFFDataDirectoryAtom(_file, 5, size);
     uint64_t offset = atom->ordinal() * sizeof(llvm::object::data_directory);
----------------
You need to sync your repository to head.

================
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;
+  }
----------------
Ron Ofir wrote:
> Richard wrote:
> > 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?
> I thought it would be useful for other tasks too, but I couldn't find any such class in the LLVM code base, so I guess it isn't?
> 
> You're right, a platform-independent way of doing buffer IO would be good. What about stl::streambuf? Or maybe it won't be platform-independent?
I think this will yield a proper COFF executable on the BE machine. Ideally I think we should use the structs defined in llvm/Support/COFF.h instead of a bare uint8 vector, and convert it to uint8 vector afterwards. That's independent from this fix so you don't need to do that, though.


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