[LLVMdev] awkward object file abstractions

[Sean Silva]

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>