[PATCH] D27073: Object: Extract a ModuleSymbolTable class from IRObjectFile.

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added inline comments.


================
Comment at: llvm/include/llvm/Object/ModuleSymbolTable.h:42
+  ArrayRef<Symbol> symbols() const { return SymTab; }
+  void addModule(Module *M);
+
----------------
mehdi_amini wrote:
> pcc wrote:
> > mehdi_amini wrote:
> > > Could it take a `MemoryBufferRef` and construct a lazy module that it would own? The fact that a Module is created should be an implementation detail.
> > > 
> > > That seems closer to the goal of having a symbol table in the bitcode file, and will help designing the client APIs appropriately.
> > > 
> > So the idea here is that this class would be the low-level interface to be used in the case where you know you're dealing with an actual IR module in memory. That's why the class exposes GlobalValues for example.
> > 
> > When symbol tables are introduced, there would be a separate class that would be the low-level interface to the bitcode symbol table. That class would be used by IRObjectFile and lto::InputFile. lib/LTO would also continue to use ModuleSymbolTable in places like LTO::addRegularLTO where it deals with a loaded module.
> > 
> > I'm sorry if I didn't make this clear enough in the discussion on D26951.
> > 
> If this is the low-level interface, what is the high-level one that abstracts away the difference between the low-level ones?
> I wouldn't expect the low-level ones to be used in IRObjectFile or lib/LTO, why is that?
> 
The next higher level interface would be the one that can provide a "bitcode symbol table" for any module, including modules without symbol tables or with old symbol tables, by creating the symbol table on the fly if necessary. Something like:
`Expected<std::unique_ptr<MemoryBuffer>> getSymbolTable(MemoryBufferRef Buf);`

where the MemoryBuffer would own the symbol table if it needed to be created, or would point inside Buf if not.

That way, no abstraction is needed between in-memory modules and bitcode symbol tables; clients can always just use a bitcode symbol table.

As long as symbol tables don't exist, we're using ModuleSymbolTable in IRObjectFile and lib/LTO. It should be easy enough to switch both of those classes to using `getSymbolTable` and the bitcode symbol table reader thanks to the work I've done to hide  the Module.


https://reviews.llvm.org/D27073