Skip to content
  1. Nov 16, 2012
  2. Nov 05, 2012
    • Andrew Kaylor's avatar
      Add a method to indicate section address re-assignment is finished. · a714efc1
      Andrew Kaylor authored
      Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress).  In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved.  To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied.
      
      llvm-svn: 167400
      a714efc1
    • Jim Grosbach's avatar
      lli: Initialize the native asm parser for inline assembly. · 2cce3f91
      Jim Grosbach authored
      MCJIT supports inline assembly, but requires the asm parser to do so.
      Make sure to link it in and initialize it.
      
      llvm-svn: 167392
      2cce3f91
  3. Nov 01, 2012
  4. Oct 29, 2012
  5. Oct 12, 2012
  6. Oct 05, 2012
    • NAKAMURA Takumi's avatar
      lli: [MCJIT] Suppress "__main" for cygming in... · a549b51a
      NAKAMURA Takumi authored
      lli: [MCJIT] Suppress "__main" for cygming in LLIMCJITMemoryManager::getPointerToNamedFunction(), like legacy JITMemoryManager's.
      
      CRT's __main (aka premain) invokes global ctors on cygming. See also PR3897.
      
      llvm-svn: 165312
      a549b51a
  7. Sep 20, 2012
  8. Sep 05, 2012
    • Jim Grosbach's avatar
      MCJIT: Add faux remote target execution to lli for the MCJIT. · 0f435d08
      Jim Grosbach authored
      Simulate a remote target address space by allocating a seperate chunk of
      memory for the target and re-mapping section addresses to that prior to
      execution. Later we'll want to have a truly remote process, but for now
      this gets us closer to being able to test the remote target
      functionality outside LLDB.
      
      rdar://12157052
      
      llvm-svn: 163216
      0f435d08
  9. Aug 29, 2012
    • Jim Grosbach's avatar
      LLI: move instruction cache tweaks. · 748b9478
      Jim Grosbach authored
      Invalidate the instruction cache right before we start actually executing code, otherwise
      we can miss some that came later. This is still not quite right for a truly lazilly
      compiled environment, but it's closer.
      
      llvm-svn: 162803
      748b9478
  10. May 20, 2012
  11. May 19, 2012
  12. May 16, 2012
  13. Apr 29, 2012
  14. Apr 18, 2012
  15. Mar 13, 2012
  16. Jan 16, 2012
  17. Jan 11, 2012
  18. Oct 16, 2011
  19. Aug 24, 2011
  20. Jul 20, 2011
  21. Jul 19, 2011
  22. Mar 18, 2011
    • Jim Grosbach's avatar
      Beginnings of MC-JIT code generation. · 7b162490
      Jim Grosbach authored
      Proof-of-concept code that code-gens a module to an in-memory MachO object.
      This will be hooked up to a run-time dynamic linker library (see: llvm-rtdyld
      for similarly conceptual work for that part) which will take the compiled
      object and link it together with the rest of the system, providing back to the
      JIT a table of available symbols which will be used to respond to the
      getPointerTo*() queries.
      
      llvm-svn: 127916
      7b162490
  23. Nov 29, 2010
  24. Nov 17, 2010
  25. Nov 13, 2010
  26. Oct 22, 2010
  27. Aug 28, 2010
  28. Apr 15, 2010
  29. Feb 05, 2010
  30. Jan 27, 2010
    • Jeffrey Yasskin's avatar
      Kill ModuleProvider and ghost linkage by inverting the relationship between · 091217be
      Jeffrey Yasskin authored
      Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
      GlobalValues now, and doesn't provide modules, it's renamed to
      "GVMaterializer". Code that used to need a ModuleProvider to materialize
      Functions can now materialize the Functions directly. Functions no longer use a
      magic linkage to record that they're materializable; they simply ask the
      GVMaterializer.
      
      Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
      the functions that refer to it. Instead, because Module now exposes the same
      functionality ModuleProvider used to, we store a Module* in any
      LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
      other languages still use the ModuleProvider concept.  It would probably be
      worth some time to update them to follow the C++ more closely, but I don't
      intend to do it.
      
      Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
      
      llvm-svn: 94686
      091217be
  31. Oct 27, 2009
  32. Oct 21, 2009
  33. Oct 16, 2009
Loading