search for: plansch

Hello LLVM-people, I have a question! Lets take I have two bc-files: "Plansch.bc" and "Becken.bc" "Plansch.bc" has an external variable which will be found in "Becken.bc" "Becken.bc" has also an external variable which will be found in " Plansch.bc" They cross reference each other. As I understand - the ExecutionEngine...

...all this on Hard Mode. ;) Yeah it was a silly thought… sorry xO > The part of your use case that is the most opaque to me is the renaming. When you see a reference to "test" in some object, how do you decide that it should resolve to the definition of "test" in, for example, Planschi, as opposed to some other module? Do you just have a list of modules that you check in-order until you find a matching symbol name? You wouldn’t find a reference to “test”, you would find “Planschi_test”. We would first try resolving that with the standard C library functions. If this fails, then...

Hey Lang, Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O< With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file was loaded by another process – or not. To understand the MU and MR things better…. I try now to explain the flow of program, when somebody would add an IR file to it – n...

...VM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] ORC JIT - different behaviour of ExecutionSession.lookup? Hi Bjoern, Even though the "tryToGenerate" function of my DefinitionGenerator returned a "llvm::orc::SymbolsNotFound" for the "?_Plansch_test@@3HA", I got an address for "? That's because you're issuing the lookup with RequiredState == SymbolState::Resolved. This means that your query will return as soon as "?Sampler@@YAXXZ" is assigned an address. In the JIT linker(s) addresses are assigned before exter...