[Lldb-commits] [PATCH] D72751: [LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging

Paolo Severini via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Jan 29 16:42:03 PST 2020


paolosev added a comment.

Regarding:

>> - make the base DynamicLoader class instantiatable, and use it whenever we fail to find a specialized plugin
>> - same as above, but only do that for ProcessGDBRemote instances
>> - make ProcessGDBRemote call LoadModules() itself if no dynamic loader instance is available WDYT?
> 
> I am fine with 1 as long as we document the DynamicLoader class to say that it will call Process::LoadModules() and will be used if no specialized loader is needed for your platform. I would like to a see a solution that will work for any process plug-in and not just ProcessGDBRemote. If we change solution 3 above to say "Make lldb_private::Process call LoadModules() itself if no dynamic loader instance is available" then solution 3 is also fine.

there is a problem: if I remove DynamicLoaderWasmDYLD what happens is that `DynamicLoaderStatic` is found as a valid loader for a triple like **"wasm32-unknown-unknown-wasm"** because the Triple::OS is llvm::Triple::UnknownOS (I found out the hard way when I was registering DynamicLoaderWasmDYLD after DynamicLoaderStatic :-)).
There is an explicit check for UnknownOS:

  DynamicLoader *DynamicLoaderStatic::CreateInstance(Process *process,
                                                     bool force) {
    bool create = force;
    if (!create) {
      const llvm::Triple &triple_ref =
          process->GetTarget().GetArchitecture().GetTriple();
      const llvm::Triple::OSType os_type = triple_ref.getOS();
      if ((os_type == llvm::Triple::UnknownOS))
        create = true;
    }
    ...
  
  call stack:
  DynamicLoaderStatic::CreateInstance(lldb_private::Process * process, bool force) Line 29
  DynamicLoader::FindPlugin(lldb_private::Process * process, const char * plugin_name) Line 52
  lldb_private::process_gdb_remote::ProcessGDBRemote::GetDynamicLoader() Line 3993
  lldb_private::Process::CompleteAttach() Line 2931
  lldb_private::Process::ConnectRemote(lldb_private::Stream * strm, llvm::StringRef remote_url) Line 3022

Could ProcessGDBRemote::GetDynamicLoader behave differently just when the architecture is wasm32, maybe? But then it is probably cleaner to add this plugin class, what do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72751/new/

https://reviews.llvm.org/D72751





More information about the lldb-commits mailing list