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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
