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

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

In https://reviews.llvm.org/D27073#610238, @mehdi_amini wrote:

> In https://reviews.llvm.org/D27073#610236, @pcc wrote:
>
> > Not sure if we'll need accessors. I'd expect that clients which need this information (essentially just the symbol table writer, eventually) would just pull the information out of the module that they presumably have
>
>
> The BitcodeModule you mean? Because we're not supposed to have a llvm::Module anymore (the patch I had was removing `llvm::Module` entirely from `LTOModule` I believe, and still exposing `LTOModule::getTargetTriple`.


Sorry, I meant that we wouldn't need accessors such as getTargetTriple() on ModuleSymbolTable, because as I mentioned that's the class we'll use for going from IR modules to symbol tables, and if you're starting from an IR module then you obviously already have an IR module that you can call accessors on.

In {LTOModule,lto::InputFile,IRObjectFile} we'd eventually be using something like a BitcodeSymtabReader class on which it seems perfectly reasonable to expose these accessors which could read from the bitcode symbol table.

>> I don't think I understand why we'd want all of the module asm. I'd have imagined that we would serialize the AsmSymbols along with the IR symbols. Or is that the IR change you were alluding to?
> 
> The issue is that we can't make Bitcode serialization dependent on the ASM Parser. So we'd need to change the IR representation for inline ASM. We discussed it here https://llvm.org/bugs/show_bug.cgi?id=28970

Thanks for the pointer, I'll take a look. It looks like this happened while I was on vacation and I must have missed it.


https://reviews.llvm.org/D27073