Keno Fischer
2015-Apr-16 00:01 UTC
[LLVMdev] [RuntimeDyld] Heads up non-X86 RuntimeDyldELF users
This is a heads up for those of you using RuntimeDyldELF (directly or indirectly through e.g. MCJIT) on targets other than X86. I have just committed http://reviews.llvm.org/rL235060. This commit changes the way that relocations work internally on a number of platforms with the goal of allowing us to free the unrelocated object file earlier. It should not in general change the observed behavior. I have tested this on X86. Other platforms represent my best understanding of how those relocations should work, but I may have missed something because I do not have access to those platforms. If you're using RuntimeDyldELF and are seeing failures after the above commit, please let us know so we can get them sorted out. We will keep the current ugly workarounds in place for a couple of days, so this commit can be reverted if it breaks the bots. Keno -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150415/831d0af9/attachment.html>
Lang Hames
2015-Apr-16 01:58 UTC
[LLVMdev] [RuntimeDyld] Heads up non-X86 RuntimeDyldELF users
This issue has been lurking for a long time, it's really great to see it getting fixed. Thanks very much Keno! RuntimeDyldELF target maintainers: If you see failures related to this patch, providing a RuntimeDyldChecker regression test will be a huge help in tracking down the issue. See test/ExecutionEngine/RuntimeDyld/* for examples of how to write these, or ping me on the lists or IRC. Cheers, Lang.> On Apr 15, 2015, at 5:01 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > This is a heads up for those of you using RuntimeDyldELF (directly or indirectly through e.g. MCJIT) on targets other than X86. > I have just committed http://reviews.llvm.org/rL235060. > > This commit changes the way that relocations work internally > on a number of platforms with the goal of allowing us to free the > unrelocated object file earlier. It should not in general change the observed > behavior. > > I have tested this on X86. Other platforms represent my best understanding > of how those relocations should work, but I may have missed something because > I do not have access to those platforms. If you're using RuntimeDyldELF and are seeing failures after the above commit, please let us know so we can get them sorted out. > > We will keep the current ugly workarounds in place for a couple of days, so this commit > can be reverted if it breaks the bots. > > Keno-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150415/62cdd6d4/attachment.html>
Keno Fischer
2015-Apr-16 02:04 UTC
[LLVMdev] [RuntimeDyld] Heads up non-X86 RuntimeDyldELF users
I've seen two buildbot failures so far, but I think I tracked down the problem. Fixed in http://reviews.llvm.org/rL235070. We'll see after the next buildbot cyle. On Wed, Apr 15, 2015 at 8:01 PM, Keno Fischer <kfischer at college.harvard.edu> wrote:> This is a heads up for those of you using RuntimeDyldELF (directly or > indirectly through e.g. MCJIT) on targets other than X86. > I have just committed http://reviews.llvm.org/rL235060. > > This commit changes the way that relocations work internally > on a number of platforms with the goal of allowing us to free the > unrelocated object file earlier. It should not in general change the > observed > behavior. > > I have tested this on X86. Other platforms represent my best understanding > of how those relocations should work, but I may have missed something > because > I do not have access to those platforms. If you're using RuntimeDyldELF > and are seeing failures after the above commit, please let us know so we > can get them sorted out. > > We will keep the current ugly workarounds in place for a couple of days, > so this commit > can be reverted if it breaks the bots. > > Keno >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150415/b17d4aff/attachment.html>