[Lldb-commits] [PATCH] D132433: [lldb] Teach LLDB about filesets

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

`Process::ReadModuleFromMemory()` takes a FileSpec and header address in memory (and a size to read, default 512 bytes).  It calls through `Module::GetMemoryObjectFile`.  That reads the 512 bytes of memory into a buffer and calls `ObjectFile::FindPlugin` class method for finding the correct plugin (via PluginManager's ObjectFileCreateMemoryInstance methods), finally hitting something like `ObjectFileMachO::CreateMemoryInstance`.

It looks like `ObjectContainer` is currently a pure virtual class; we'd need to add a base class method `FindPlugin` for working with a memory module.  Process would need a `Process::ReadObjectContainerFromMemory()` or something?  Not sure if that's the right idea - but we don't know what kind of container it is when we have a Process and a header address in memory.



================
Comment at: lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp:201
+            : ObjectFile::MapFileData(m_file, header_and_lc_size, m_offset);
+    m_data.SetData(data_sp, m_offset, header_and_lc_size);
+  }
----------------
This started with a memory buffer of the mach header in m_data, now we've read the mach header and the load commands. It seems like we should replace the original data buffer with the memory we just read.  A quick look at `ObjectFileMachO::ParseHeader()`, it replaces the entire m_data.


================
Comment at: lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp:255
+  uint32_t filetype = data.GetU32(&offset);
+  return filetype == llvm::MachO::MH_FILESET;
+}
----------------
This file has a `using` at the top, don't need to qualify the constant.  (there's a handful of other instances, I note one of them)


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

https://reviews.llvm.org/D132433