search for: getsymboladdress

...x (a): ObjectFile factory methods return ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error appropriately. (b) is harder. The current approach is to use std::error_code as a return type, and store the result in by-reference argument, for instance: std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); I wanted to follow this approach in a proposed large MachO API change (http://reviews.llvm.org/D10111), but it raised discussion on whether this approach is right. Moving this discussion here. I see the following options: 1. Use the current approach: std:...

...hods return > ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error > appropriately. > > (b) is harder. The current approach is to use std::error_code as a return > type, and store the result in by-reference argument, for instance: > std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); > > I wanted to follow this approach in a proposed large MachO API change > (http://reviews.llvm.org/D10111), but it raised discussion on whether this > approach is right. > Moving this discussion here. I see the following options: > > 1....

...hods return > ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error > appropriately. > > (b) is harder. The current approach is to use std::error_code as a return > type, and store the result in by-reference argument, for instance: > std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); > > I wanted to follow this approach in a proposed large MachO API change > (http://reviews.llvm.org/D10111 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10111&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1L...

...ptr<ObjectFile>>, and we should propagate the error >>> appropriately. >>> >>> (b) is harder. The current approach is to use std::error_code as a >>> return type, and store the result in by-reference argument, for instance: >>> std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &Res); >>> >>> I wanted to follow this approach in a proposed large MachO API change >>> (http://reviews.llvm.org/D10111 >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10111&d=AwMFaQ&c=8hUWFZ...

Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return findSymbol(MangledName, CheckFunctionsOnly).getAddress();}* Now with the curren...

...RTDyldSymbolTable::const_iterator Loc = GlobalSymbolTable.find(Name); if (Loc == GlobalSymbolTable.end()) { // This is an external symbol, try to get its address from the symbol // resolver. Addr = Resolver.findSymbol(Name.data()).getAddress(); // The call to getSymbolAddress may have caused additional modules to // be loaded, which may have added new entries to the // ExternalSymbolRelocations map. Consquently, we need to update our // iterator. This is also why retrieval of the relocation list // associated with this symbol is deferre...

...RTDyldSymbolTable::const_iterator Loc = GlobalSymbolTable.find(Name); if (Loc == GlobalSymbolTable.end()) { // This is an external symbol, try to get its address from the symbol // resolver. Addr = Resolver.findSymbol(Name.data()).getAddress(); // The call to getSymbolAddress may have caused additional modules to // be loaded, which may have added new entries to the // ExternalSymbolRelocations map. Consquently, we need to update our // iterator. This is also why retrieval of the relocation list // associated with this symbol is deferre...

...quot;In relocatable files, st_value holds a section offset for a defined symbol. That is, > st_value is an offset from the beginning of the section that st_shndx identifies." (*) > > Therefore, when queried about a symbol's address what would the right answer be? In ELFObjectFile::getSymbolAddress, previously, it was simply symb->st_value (which is the relative offset to the section). Now, Section->sh_addr is added to reflect the actual address of the symbol. > > Ignoring for the moment the change this imposes on objdump & nm (which can be amended), what would the expected ad...

...l common interface that makes them easy to compose: class SomeLayer { private: // Implementation details public: // Implementation details typedef ??? Handle; template <typename ModuleSet> Handle addModuleSet(ModuleSet&& Ms); void removeModuleSet(Handle H); uint64_t getSymbolAddress(StringRef Name, bool ExportedSymbolsOnly); uint64_t lookupSymbolAddressIn(Handle H, StringRef Name, bool ExportedSymbolsOnly); }; Layers are usually designed to sit one-on-top-of-another, with each doing some sort of useful work before handing off to the layer below it. The layers that are curr...

Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options is to use the LazyFunctionCreator which is implemented in both JIT and MCJIT. Andy - MCJIT::getPointerToFunction d...

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of

...multiple Modules just aren't that useful. > Sure. This problem should be tackled in the wrappers around the components, rather than the components themselves. See MCJITReplacement::addModule for an example. > (4) > Q. What happened to "finalize"? > A. In the Orc APIs, getSymbolAddress automatically finalizes as necessary > before returning addresses to the client. When you get an address back from > getSymbolAddress, that address is ready to call. > > As long as this is true for the high level API and *not* the low level one > (as is true today), this seems fine....

...RTDyldSymbolTable::const_iterator Loc = GlobalSymbolTable.find(Name); if (Loc == GlobalSymbolTable.end()) { // This is an external symbol, try to get its address from the symbol // resolver. Addr = Resolver.findSymbol(Name.data()).getAddress(); // The call to getSymbolAddress may have caused additional modules to // be loaded, which may have added new entries to the // ExternalSymbolRelocations map. Consquently, we need to update our // iterator. This is also why retrieval of the relocation list // associated with this symbol is deferre...

Oh - I know what this is. You were running this on Linux, right? On MacOS I think the symbol is getting double mangled while going through MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets compiled to "_foo" in the object file, and then "_foo" gets mangled to "__foo" when we look it up. Linux doesn't do assembly level name-mangling, so this bug doesn't show up there. Since applying this fixes Li...

Hi Andrew, I used the latest code from trunk. GlobalSymbolTable is being used in MCJIT. I guess it wasn't clear from the proposal that the user program will be modified to indicate that the callback should happen at that point in the code. The objective is to call some of the functions which belong to lli or the ExecutionEngine. Thanks, Sumeeth On Fri, Nov 1, 2013 at 5:40 PM, Kaylor,

...value means: "In relocatable files, st_value holds a section offset for a defined symbol. That is, st_value is an offset from the beginning of the section that st_shndx identifies." (*) Therefore, when queried about a symbol's address what would the right answer be? In ELFObjectFile::getSymbolAddress, previously, it was simply symb->st_value (which is the relative offset to the section). Now, Section->sh_addr is added to reflect the actual address of the symbol. Ignoring for the moment the change this imposes on objdump & nm (which can be amended), what would the expected address be...

...r with the number of added (but not loaded) modules, since it has to (possibly) search for the correct module while old code directly searches the correct module. To solve the issue, getFunctionAddress could get an optional Module "hint" (=NULL by default) which - if provided - will make getSymbolAddress skip calling findModuleForSymbol (a very slow operation) and instead directly use the Module provided. Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131020/04318b9d/attachment.html>

...gt; private: > Â // Implementation details > public: > Â // Implementation details > > Â typedef ??? Handle; > > Â template <typename ModuleSet> > Â Handle addModuleSet(ModuleSet&& Ms); > > Â void removeModuleSet(Handle H); > > Â uint64_t getSymbolAddress(StringRef Name, bool ExportedSymbolsOnly); > > Â uint64_t lookupSymbolAddressIn(Handle H, StringRef Name, bool > ExportedSymbolsOnly); > }; > > Layers are usually designed to sit one-on-top-of-another, with each > doing some sort of useful work before handing off to the laye...

...onst std::string &Name, bool AbortOnFailure). So, the hypercall resolution can be done here. In MCJIT, during finalizeObject(), all the symbol relocations are finalized. In the Memory Managers, the external symbols are resolved. So, the hypercall resolution can be done in LinkingMemoryManager::getSymbolAddress(). In JIT::getPointerToNamedFunction(), check whether the function name is PerformCustomCallback and store the address of the function PerformCustomCallback in the global table. So the next time a call happens, JIT will get the address directly from the table. In MCJIT, in LinkingMemoryManage...

...obalSymbolTable.find(Name); > > if (Loc == GlobalSymbolTable.end()) { > > > // This is an external symbol, try to get its address from the symbol > > // resolver. > > Addr = Resolver.findSymbol(Name.data()).getAddress(); > > > // The call to getSymbolAddress may have caused additional modules to > > // be loaded, which may have added new entries to the > > > // ExternalSymbolRelocations map. Consquently, we need to update our > > // iterator. This is also why retrieval of the relocation list > > // a...