search for: findmodulesdefiningsymbols

Hi Rafael and other LLVM devs, I'm currently upgrading a project that uses LLVM that links a bitcode archive (a C library) with a module. Originally we used Linker::LinkInFile() but that was removed by r172749. So I started looking for an alternative and I found Archive::findModulesDefiningSymbols() which looked very promising as it would allow me to very easily implement linking a bitcode archive with a module efficiently (i.e. only call Linker::LinkModules() on the relevant bitcode modules inside the bitcode archive). Before I started I thought I'd better check that this API was still...

...ael and other LLVM devs, > > I'm currently upgrading a project that uses LLVM that links a bitcode > archive (a C library) with a module. Originally we used > Linker::LinkInFile() but that was removed by r172749. So I started > looking for an alternative and I found > Archive::findModulesDefiningSymbols() which looked very promising as > it would allow me to very easily implement linking a bitcode archive > with a module efficiently (i.e. only call Linker::LinkModules() on the > relevant bitcode modules inside the bitcode archive). > > Before I started I thought I'd better check...

...>> >> I'm currently upgrading a project that uses LLVM that links a bitcode >> archive (a C library) with a module. Originally we used >> Linker::LinkInFile() but that was removed by r172749. So I started >> looking for an alternative and I found >> Archive::findModulesDefiningSymbols() which looked very promising as >> it would allow me to very easily implement linking a bitcode archive >> with a module efficiently (i.e. only call Linker::LinkModules() on the >> relevant bitcode modules inside the bitcode archive). >> >> Before I started I thought...

Hi Philip, Thank you very much for your comments. I think I’ve discovered a root cause. The problem was in linking bit code archive files with the module. At some point, std::set<Module*> is used and iterated over. I believe this was the reason why e.g. It worked consistently with ASLR turned off and produced non-deterministic output otherwise. I changed that bit to use vector instead and