llvm dev - Sep 2014 - [LLVMdev] 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

On Tue, Sep 9, 2014 at 9:07 PM, Steve King <steve at metrokings.com>
wrote:
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140910/6395f9c9/attachment.html>

On Wed, Sep 10, 2014 at 11:50 AM, Sean Silva <chisophugis at gmail.com>
wrote:
> 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.
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.