labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
Augmenting the architecture with the target information sounds right to me. If we're reading a module from memory, then we already have a running target, and I consider that information more reliable (since it comes from os/lldb-server) than the object file architecture (which is just random bits in process memory). I might even go so far as to say that if we detect that the module and target ArchSpecs substantially differ (for some meaning of "substantially"), we should reject the attempt to create the module in the first place. Maybe we even do that already at some level? Unfortunately, I think testing this is going to be hard. The infrastructure for testing in-memory object files is very under-developed. I think the best attempt would be to have a test program which creates some object files in memory (via llvm jit, or perhaps by loading pre-prepared binaries from disk), and then using the gdb jit interface to notify lldb about it. But I don't think we have anything similar to this currently. In D58405#1402908 <https://reviews.llvm.org/D58405#1402908>, @aprantl wrote: > > a good guess is the triple that the target executable was compiled for. > > What does this do when the executable has multiple slices, such as a Mach-O > universal binary? I don't think this should be an issue since a Module object always points to a specific slice in the fat binary. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58405/new/ https://reviews.llvm.org/D58405 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
