Hello LLVM, I'm trying to make symbolizing work in llvm-objdump. This comment in ObjectFile.h gives me some heartburn: 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: > > > 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 llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <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.
Reasonably Related Threads
- [LLVMdev] SymbolRef and getSize
- Interest in integrating a linux perf JITEventListener?
- How to concatenate Ogg in the browser JS?
- [LLVMdev] DebugInfo library and relocations in the .debug_line section
- [LLVMdev] Object File Library. llvm-nm changed to match binutils-nm for COFF and ELF (32, little endian).