Details
- Reviewers
jasonmolenda - Commits
- rG48506fbbbf27: [lldb] Teach LLDB about Mach-O filesets
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This all looks great.
I am working on a patch that will build on this, but I will be working with a memory image which needs the CreateMemoryInstance() ObjectFile interface implemented, and in my case, I'm very much hoping to avoid reading the entire fileset out of memory -- I'd like it if we don't read more than the mach header & load commands from the fileset, so I can query for a single entry by name in the fileset (e.g. "com.apple.kernel"). If the memory ObjectContainerMachOFileset created a memory ObjectFile for that name, that's fine, I'll be reading it from memory soon to get the UUID anyway out of the load commands. (ObjectFileMachO will only read the header + load commands for a memory module, until you touch the symbol table.)
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.
lldb/source/Plugins/ObjectContainer/Mach-O-Fileset/ObjectContainerMachOFileset.cpp | ||
---|---|---|
202 | 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. | |
256 | 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) |
Reviewed this a little too close to bed time ;) - Jonas asked me if I really needed this up at the generic Process level, and I remembered that the one use case I am writing currently for this will be down in Darwin-specific code, so I can create the memory instance of the macho fileset explicitly. This patch looks good to me.
I added the ability to call ObjectContainer::FindPlugin which allows you to create a Mach-O fileset from memory without actually having to know it's a fileset. I think that should cover Jason's use-case without needing to thread it through process.
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.