search for: symboltable

...hStringRef, int> >, llvm::CachedHashStringRef, int, llvm::DenseMapInfo<llvm::CachedHashStringRef>, llvm::detail::DenseMapPair<llvm::CachedHashStringRef, int> >::insert(std::pair<llvm::CachedHashStringRef, int>&&) (DenseMap.h:199) ==5467== by 0x516836: lld::elf::SymbolTable::insert(llvm::StringRef) (SymbolTable.cpp:225) ==5467== by 0x516A21: lld::elf::SymbolTable::insert(llvm::StringRef, unsigned char, unsigned char, bool, lld::elf::InputFile*) (SymbolTable.cpp:260) ==5467== by 0x51B88C: void lld::elf::SymbolTable::addShared<llvm::object::ELFType<(llvm::su...

...lvm::CachedHashStringRef, int, llvm::DenseMapInfo<llvm::CachedHashStringRef>, >> llvm::detail::DenseMapPair<llvm::CachedHashStringRef, int> >> >::insert(std::pair<llvm::CachedHashStringRef, int>&&) (DenseMap.h:199) >> ==5467== by 0x516836: lld::elf::SymbolTable::insert(llvm::StringRef) >> (SymbolTable.cpp:225) >> ==5467== by 0x516A21: lld::elf::SymbolTable::insert(llvm::StringRef, >> unsigned char, unsigned char, bool, lld::elf::InputFile*) >> (SymbolTable.cpp:260) >> ==5467== by 0x51B88C: void lld::elf::SymbolTable::ad...

I was looking at the SymbolTable code in LLD COFF and ELF recently, and I’m confused by the use of CachedHashStringRef. From what I understand, a CachedHashStringRef combines a StringRef with a computed hash. There’s no caching going on in the CachedHashStringRef itself; that is, if you construct CachedHashStringRef("foo&quo...

The SymbolTable is a map of Type* to a map of names to Value*. This means that in order to lookup something by name you first have to know what type it is. For the basic types this is fine because you generally always know which basic type you're after. But, for derived types, this can be quite complicated....

Hi, I'm working on bug 122, consolidating the interface to the SymbolTable class. In doing so, I found the function below which traverses the symbol table but apparently unnecessarily. Before I remove the traversal, I thought I better check with you guys. Posted this to the list because it looks like _everyone_ has edited this file :) In the code below, the IOB variable...

I was trying to look through the SymbolTable code for LLVM. What does the SymbolTable for a Module contain? Is it just GlobalVariables and Functions? How are program constants and static variables declared within functions handled? When I said program constants, I meant things like strings (e.g., char* foo = "Hello world\n";...

...= 0;" to the end of the loop should be delted because the only effect the loop has is on the IOB variable and that variable is never used after the loop. Reid. On Tue, 2004-05-11 at 18:14, Reid Spencer wrote: > Hi, > > I'm working on bug 122, consolidating the interface to the SymbolTable > class. In doing so, I found the function below which traverses the > symbol table but apparently unnecessarily. Before I remove the > traversal, I thought I better check with you guys. Posted this to the > list because it looks like _everyone_ has edited this file :) > > In the...

I really can't figure out how to get and set array indices from the c interface. so to get an element I'm calling tindex = *fn\SymbolTable(*index\name) index = LLVMBuildLoad(builder,tindex,"index") arr = *fn\SymbolTable(*array\name) arrptr = LLVMBuildLoad(Builder,arr,"arrayptr") tmp = LLVMBuildGEP(Builder,arrptr,index,0,"ptr") ptr = llvmBuildload(Builder,tmp,"ele") and to set tarr = *...

...or<tart::Defn*, 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at StringMap.h:406 #5 0x00000001000aeaa5 in llvm::StringMap<llvm::SmallVector<tart::Defn*, 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at StringMap.h:403 #6 0x00000001000aea7c in tart::SymbolTable::~SymbolTable (this=0x1016e4888) at SymbolTable.h:34 #7 0x00000001000aea45 in tart::OrderedSymbolTable::~OrderedSymbolTable (this=0x1016e4888) at SymbolTable.h:74 #8 0x00000001000aea15 in tart::OrderedSymbolTable::~OrderedSymbolTable (this=0x1016e4888) at SymbolTable.h:74 #9 0x00000001000ae809 i...

...generator for my architecture, so haven't gotten enough through everything to completely document the bytecode language. Symbol tables in LLVM are easy though. Hope this answers your question. -- Robert. At 06:04 PM 11/17/2003 -0600, Brian Fahs wrote: >I was trying to look through the SymbolTable code for LLVM. What does the >SymbolTable for a Module contain? Is it just GlobalVariables and >Functions? How are program constants and static variables declared within >functions handled? When I said program constants, I meant things like >strings (e.g., char* foo = "Hell...

...d be delted because the only effect the loop has is on the IOB > variable and that variable is never used after the loop. > > Reid. > > On Tue, 2004-05-11 at 18:14, Reid Spencer wrote: > > Hi, > > > > I'm working on bug 122, consolidating the interface to the SymbolTable > > class. In doing so, I found the function below which traverses the > > symbol table but apparently unnecessarily. Before I remove the > > traversal, I thought I better check with you guys. Posted this to the > > list because it looks like _everyone_ has edited this file...

..., llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at > StringMap.h:406 > #5 0x00000001000aeaa5 in llvm::StringMap<llvm::SmallVector<tart::Defn*, > 4u>, llvm::BumpPtrAllocator>::~StringMap (this=0x1016e4890) at > StringMap.h:403 > #6 0x00000001000aea7c in tart::SymbolTable::~SymbolTable > (this=0x1016e4888) at SymbolTable.h:34 > #7 0x00000001000aea45 in tart::OrderedSymbolTable::~OrderedSymbolTable > (this=0x1016e4888) at SymbolTable.h:74 > #8 0x00000001000aea15 in tart::OrderedSymbolTable::~OrderedSymbolTable > (this=0x1016e4888) at SymbolTable.h:74...

LLVMers, On the way to resolving bug 122, I am committing my SymbolTable rewrite. If you are working on anything that uses the SymbolTable, I suggest you read the documentation in include/llvm/SymbolTable.h. The changes I've committed reduce the use of Type::TypeTy. This static member will go away in the future, so please do not propagate new code that uses it. The...

On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > I recently updated my version of LLVM from revision 140108 to 142082, and > several things broke, most of which were easily fixed. However, I'm now > getting a "pure virtual method called" exception (__cxa_pure_virtual) which > I wasn't getting before. This is happening in the destructor of

I recently updated my version of LLVM from revision 140108 to 142082, and several things broke, most of which were easily fixed. However, I'm now getting a "pure virtual method called" exception (__cxa_pure_virtual) which I wasn't getting before. This is happening in the destructor of a statically-initialized object. (More precisely, it's blowing up in a BumpPtrAllocator,

...it seems they are not included in [Module::gbegin(), Module::gend()], insteads, they a Function objects with isExternal set to true. To me this seems a bit confusing -- it would be clearer if there we plain functions with bodies and everything else were GlobalValue. Anyther question is about SymbolTable. Is it true that it's a mapping from name to objects in Module, and than all objects accessible via SymbolsTable are either in the list of functions or in the list of global values? > If you have a GlobalValue*, please do use it, but if it's one of these > cases where the called fu...

...a function, you get a prototype. When you fill in its body, you now have a defined function. In your scheme, the function prototype and defined function objects would be different: to go from one to the other, you would have to delete the object and reallocate it. > Anyther question is about SymbolTable. Is it true that it's a mapping from > name to objects in Module, and than all objects accessible via SymbolsTable > are either in the list of functions or in the list of global values? Yup. There are also function-local symbol tables as well. I wouldn't recommend depending too muc...

...iler-rt/lib/asan/asan_new_delete.cc:82 #1 0x8c8610 in void lld::elf::BinaryFile::parse<llvm::object::ELFType<(llvm::support::endianness)1, true> >() /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/InputFiles.cpp:823:7 #2 0xb9de74 in lld::elf::SymbolTable<llvm::object::ELFType<(llvm::support::endianness)1, true> >::addFile(lld::elf::InputFile*) /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/SymbolTable.cpp:61:8 #3 0x82c46f in void lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::su...

...0x8c8610 in void >> lld::elf::BinaryFile::parse<llvm::object::ELFType<(llvm::support::endianness)1, >> true> >() >> /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/InputFiles.cpp:823:7 >> #2 0xb9de74 in >> lld::elf::SymbolTable<llvm::object::ELFType<(llvm::support::endianness)1, >> true> >::addFile(lld::elf::InputFile*) >> /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/lld/ELF/SymbolTable.cpp:61:8 >> #3 0x82c46f in void >> lld::elf::LinkerDriver::link&l...

...s the same list as what type_iterator->first would produce. Also, an attempt to access value_iterator->second->getName() produces junk names. value_iterator->second->hasName() causes segfaults. All this is compiled fine. Following is sample code and output. Code: ------------- for ( SymbolTable::type_iterator itr1 = symbTab.type_begin(), itrend1 = symbTab.type_end(); itr1 != itrend1; itr1++ ) { string typeName = itr1->first; if ( lldbprfx.compare( typeName.substr( 0, 5 ) ) != 0 ) { cerr << typeName << endl; for ( SymbolTable::value_const_iterator itr2 = symbTab....