Closed graymalkin closed 9 years ago
Could you add a comment about why this is needed at all - i.e. codegen introduces calls to functions that aren't called in the IR such as __udivdi3
Would this be accurate?
Symbol Searching is not available on Windows platforms. We'll have to use the JIT map only. This needs to be enabled for Linux x86 platforms, as the IR generated by LLVM references runtime library calls such as __udivdi3, and currently the genJitGlobalMap isn't picking those up, so applications could segfault in JITed code if they use these instructions. LLVMSymbolSearching does.
Yep, something like that is fine.
On 21/10/14 10:38, Simon Cooksey wrote:
Would this be accurate?
Symbol Searching is not available on Windows platforms. We'll have to use the JIT map only. This needs to be enabled for Linux x86 platforms, as the IR generated by LLVM references runtime library calls such as __udivdi3, and currently the genJitGlobalMap isn't picking those up, so applications could segfault in JITed code if they use these instructions. LLVMSymbolSearching does.
— Reply to this email directly or view it on GitHub https://github.com/rlsosborne/tool_axe/pull/21#issuecomment-59902545.
Richard Osborne | XMOS http://www.xmos.com
Cool - the previous commit has been amended with the extra information. :octocat:
Could you reference __udivdi3 in the comment - without this it is a bit vague.
Sorry >.< I derped with git. Fixed now
I'm struggling to get axe to build correctly on Windows >.< but once I have, I'll see if I can reproduce the bug there. Assuming it's not present then this patch should be all that's needed. If it is, however, I'll try and follow up with something better.
At a guess, and from what you've suggested, it'll probably mean changes to the
genGlobalJitMap
utility -- though I still have no great ideas on how to find all the symbols which might be needed, unless I add everything from the GCC runtime (though this seems like a bad idea).Commit message
An error occurs on 32 bit linux, where it isn't finding all the symbols needed at run time, and failing.
I've not checked behaviour on Windows x86 yet. Windows x86_64 should remain unaffected.