similar to: Understanding LLD's SymbolTable's use of CachedHashStringRef

E.g. Is it intended to be allowed to call lld::elf::link in 2 different threads at the same time? Follows is an example Valgrind error I ran into when doing the above. I'll try putting a global resource lock on invoking LLD and see if it solves the problem. ==5467== Invalid write of size 8 ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int,

Hi Andrew, LLD relies on various bits of global state which are manipulated during the link, so I wouldn't expect it to be thread safe at that level, although it does attempt to reset that global state at the start of each call to link(), so it should be callable sequentially. Regards, James On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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. It isn't always possible to know the exact type. In XPL, types are just names.

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

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";). Thanks in advance. Sincerely, Brian Brian M.

Brian, Global symbols including new named types are named in the global symbol table. In addition each function contains a local symbol table naming local items, including temporary variables. I'm busy documenting all this, but I'm also busy writing a code generator for my architecture, so haven't gotten enough through everything to completely document the bytecode language.

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 is the only thing in

I mis-stated what I think should be deleted. The block of code from "GlobalVariable *IOB = 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

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > 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"

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 =

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

And, one more weird thing in this function. The FILESize static variable is never initialized so its likely initial value is 0 due to zero fill on many MMUs. The value is never written and used as a divisor. Why hasn't this function caused an arithmetic violation? Because the IOBBase point, also a static variable is initialized to zero and never modified and used in a conditional that thwarts

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

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,

Chris Lattner wrote: > > Second, MO_ExternalSymbol is used for storing name of external > > variable/function, right? Why it's not possible to use MO_GlobalAddress, > > where returned GlobalValue* has isExternal set to true? The > > GlobalValue::getName would return the name of the symbol. > > Using the GlobalValue is certainly the preferred way if you have it.

On Mon, Nov 7, 2016 at 5:53 PM, Davide Italiano <davide at freebsd.org> wrote: > On Mon, Nov 7, 2016 at 4:43 PM, Kostya Serebryany via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> The asan bootstrap bot is unhappy with lld. >> Rui, os someone, please take a look. >> >>

The asan bootstrap bot is unhappy with lld. Rui, os someone, please take a look. http://lab.llvm.org:8011/builders/sanitizer-x86_64- linux-bootstrap/builds/138/steps/check-lld%20asan/logs/stdio ==26011==ERROR: LeakSanitizer: detected memory leaks Direct leak of 184 byte(s) in 1 object(s) allocated from: #0 0x72fab0 in operator new(unsigned long)

On Fri, 18 Jun 2004, Vladimir Prus wrote: > > actually exist in the LLVM module for the function. In particular, this > > would include any functions in a code-generator specific runtime library > > and malloc/free. The X86 code generator compiles floating point modulus > > into fmod calls, and 64-bit integer div/rem into runtime library calls. > > And why isn't

Hello, I have a couple of doubts, as listed below: 1. To list all the global variables in the module, I am iterating using type_iterator and for each Type I get, I am using value_iterator to iterate over Values . In the second iteration I am getting unexpected results. For each type obtained from type_iterator->second, value_iterator->first produces the same list as what

On 08/04/2016 01:33 PM, David Majnemer wrote: > You should never be copying or moving around Values. Why not? Is that because of this thing you also wrote in the same message: "use lists are allocated before the object"? > An llvm::Value (which GlobalVariable is a subtype of) should exist only in the heap. Trying to sort a container of such objects doesn`t require me to