awkward object file abstractions

Hello LLVM,
I'm trying to make symbolizing work in llvm-objdump. This comment in
ObjectFile.h gives me some heartburn:

https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/ObjectFile.h#L196

// The main goal of
// this is to allow SymbolRef::SymbolPimpl to point directly to the symbol
// entry in the memory mapped object file. SymbolPimpl cannot contain any
// virtual functions because then it could not point into the memory mapped
// file.

Is this still a goal and if so, why? Building symbol objects on top
of the file's memory image causes some unnatural acts, e.g. no virtual
functions, for what otherwise could be an unsurprising class
hierarchy.

Thanks,
-steve

Probably to reduce overhead. The data is already in memory in a relatively nice form; no point in duplicating it, especially when it could be very large. Could you give an example of where you would like to use a virtual function but current can’t because of this design?

I think Michael would know what possible directions there are for the design.

– Sean Silva

A hacky calculation shows clang contains 604238 symbols (debug build).
Assuming a 30-character symbol name and 18 bytes of metadata per
symbol, we get 604238 * 30 * 18 = 326MB of symbol data. That does
feel kinda heavy.