jasonmolenda wrote: > Since @JDevlieghere has more context for this effort, they can be the > approver.
I didn't want to get too deep into details not directly related to this PR, but the overall project is a mac specific one. On Darwin systems we have a shared cache, which is the combination of all the system libraries in a single block. The sections of the binaries are rearranged -- so all of the texts, all of the datas, etc., keeping within pc-relative branch offsets. And the nlist table names (linkedit segment) are all combined into one, so duplicated symbol names can be combined. The discrete library binaries don't exist in the OS, only this shared cache binary blob that is mapped into memory in every process. When lldb is debugging a process on the local computer, it checks that the UUID of the shared cache in the inferior is the same as the UUID of lldb's own shared cache, and if so, it creates ObjectFile's out of its own memory by creating a DataBufferUnowned in HostInfoMacOSX, and passing that DataBufferSP into the ObjectFile plugin finder. The change I'll work on next is to use some API to map a binary from the shared cache blob on disk into lldb's address space, instead of using lldb's own in-memory mapping of it. mmapping the shared cache in its entirety can be tricky because it's a large address range and finding room for it can be a problem, so instead there are API to map the separate sections of a binary into lldb's address space. It can create a DataBuffer of those mapped segments and create the object file from them. The problem is that the sections are not in any particular order. Normally a Mach-O binary starts with text, then data, then linkedit, and all of our Mach-O parsing depends on this. The VirutalDataExtractor allows me to create a remapping of the address where different sections got mapped into lldb's own address space into a "0-offset text" style DataBuffer, by providing a remapping, and parse it as if it's a normal Mach-O. So HostInfoMacOSX needs to create this VirtualDataExtractor with the correct remapping, pointing to the local address range for the mapped sections, and pass it to an ObjectFile plugin interface as a DataExtractorSP. The old system of everyone passing in a DataBufferSP and then ObjectFile base class creating a DataExtractor was the problem; I needed to be able to pick a subclass of DataExtractor at the HostInfoMacOSX caller point. https://github.com/llvm/llvm-project/pull/171574 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
