[PATCH] D26951: Object: Make IRObjectFile own multiple modules and enumerate symbols from all modules.

[Mehdi AMINI via llvm-commits]

mehdi_amini added a comment.

> The client's use of ModuleSymbolTable (and the rest of the lib/Object interface in general) needs to be driven by that fundamental design decision of where the split lies. So for the fat binary scenario I would see the client creating one ModuleSymbolTable (and one bitcode symbol table) for each architecture, and the IRObjectFile growing a way to choose the architecture (as we do in MachOObjectFile for example).

Right, but the "triple" as a discriminator seems arbitrary to me: what about use cases where we ship a "fat" object file containing bitcode for a non-optimized debug build of the module and an optimized one?  Or for building with and without options like freestanding? Or with and without the sanitizers?


https://reviews.llvm.org/D26951