[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