[PATCH] Preliminary support for dynamically loadable coff objects

Andy Ayers andya at microsoft.com
Thu Feb 26 13:05:51 PST 2015


REPOSITORY
  rL LLVM

================
Comment at: lib/ExecutionEngine/RuntimeDyld/CMakeLists.txt:8
@@ -6,2 +7,3 @@
   RuntimeDyldMachO.cpp
+  Targets/RuntimeDyldCOFFX86_64.cpp
   )
----------------
zturner wrote:
> Minor CMake style nit.  The relationship between this folder and Targets is a little awkward (not because of your doing, seems historical).  In any case, adding a file from a subfolder into this library can be strange to someone using an IDE because they will see RuntimeDyldCOFFX86_64.cpp in the same file list as the rest, even though it's in a different location on disk.  
> 
> It might be a little better if "Targets" showed up as a folder in the IDE, with RuntimeDyldCOFFx86_64.cpp showing up under that folder.  An example of the CMake needed to do this is in \lib\DebugInfo\PDB\CMakeLists.txt.  It's only a couple of boiler plate lines.
Sounds like we're leaving this as is, per your investigation.

================
Comment at: lib/ExecutionEngine/RuntimeDyld/Targets/RuntimeDyldCOFFX86_64.cpp:94
@@ +93,3 @@
+  SectionEntry &Section = Sections[SectionID];
+  uint8_t *Target = Section.Address + Offset;
+  switch (RelType) {
----------------
andrew.w.kaylor wrote:
> Shouldn't you be using Section.ObjAddress here?
You should get the same result either way, but I agree the intent might be clearer if we read from the original object instead of its loaded copy.

However once we implement the rel forms (which I am ending up doing as part of adding test cases) we need to know the actual address of the location to fix up; then it seems simpler to use that address to fetch any possible target displacement too.

http://reviews.llvm.org/D7793

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list