On 2017-02-28 18:36, Greg Clayton wrote:

On Feb 28, 2017, at 4:19 AM, Carlo Kok via lldb-dev
<lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote:

As far as I can tell from reading the source LLDB has facilities to
load a "jitted" clang fragment as an object file, load it into the
target process "run" it and unload it. Could this process be reused
externally? Say from the SB or lower level apis?

What I want to accomplish is allow better expression evaluation for my
own languages by compling a piece of code to an object file (coff/elf,
whatever), passing all locals/args as arguments to this and getting
the evaluated result out of it. Is something like this possible?

Yes. In SBProcess you can load a shared library and unload it:

  //------------------------------------------------------------------
  /// Load a shared library into this process.
  ///
  /// @param[in] remote_image_spec
  ///     The path for the shared library on the target what you want
  ///     to load.
  ///
  /// @param[out] error
  ///     An error object that gets filled in with any errors that
  ///     might occur when trying to load the shared library.
  ///
  /// @return
  ///     A token that represents the shared library that can be
  ///     later used to unload the shared library. A value of
  ///     LLDB_INVALID_IMAGE_TOKEN will be returned if the shared
  ///     library can't be opened.
  //------------------------------------------------------------------
  uint32_tLoadImage(lldb::SBFileSpec&remote_image_spec,
lldb::SBError&error);

  //------------------------------------------------------------------
  /// Load a shared library into this process.
  ///
  /// @param[in] local_image_spec
  ///     The file spec that points to the shared library that you
  ///     want to load if the library is located on the host. The
  ///     library will be copied over to the location specified by
  ///     remote_image_spec or into the current working directory with
  ///     the same filename if the remote_image_spec isn't specified.
  ///
  /// @param[in] remote_image_spec
  ///     If local_image_spec is specified then the location where the
  ///     library should be copied over from the host. If
  ///     local_image_spec isn't specified, then the path for the
  ///     shared library on the target what you want to load.
  ///
  /// @param[out] error
  ///     An error object that gets filled in with any errors that
  ///     might occur when trying to load the shared library.
  ///
  /// @return
  ///     A token that represents the shared library that can be
  ///     later used to unload the shared library. A value of
  ///     LLDB_INVALID_IMAGE_TOKEN will be returned if the shared
  ///     library can't be opened.
  //------------------------------------------------------------------
  uint32_tLoadImage(constlldb::SBFileSpec&local_image_spec,
                     constlldb::SBFileSpec&remote_image_spec,
                     lldb::SBError&error);

  lldb::SBErrorUnloadImage(uint32_timage_token);


Does that work with (non shared, not linked) object files too? Because SO's have different visibility rules (And on windows they work completely different with exports/imports) which will probably interfere with using it as underlying logic for evaluating?

--
Carlo Kok
RemObjects Software
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to