Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime Compiled C++ http://cppcast.com/2016/05/doug-binks/ Am 21.11.17 um 14:20 schrieb Nikodemus Siivola via llvm-dev:> Transform the atexit into equivalent code you can control, run it > before the destructors of the JIT engine run? > > > On Tue, Nov 21, 2017 at 12:13 PM, Alex Denisov via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > It's not the job of the Orc engine. > > I could argue about this, but I won’t :) > > > Just don't use atexit. > > The problem is that I run third-party programs. I cannot control them. > > > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via > llvm-dev wrote: > >> JIT allocates and maps some memory for the execution. Some > function X at address 0xdeadbeef is part of this memory. > >> JIT calls a code that passes the X to atexit. > >> JIT deallocates and unmaps the memory used for execution > (either via objectLayer.removeObjectSet or by calling JIT's > destructors) > >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which > does not belong to 'us' anymore, which leads to the crash. > > > > Sounds plausible. > > > >> Given that my assumption is correct what can we do about this? > Is there > >> anything that can be done to cover this case inside of the Orc > engine? > > > > It's not the job of the Orc engine. Just don't use atexit. > > > > Joerg > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- https://weliveindetail.github.io/blog/ https://cryptup.org/pub/stefan.graenitz at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171123/edeb05ed/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x07C9F580.asc Type: application/pgp-keys Size: 1717 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171123/edeb05ed/attachment.key> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171123/edeb05ed/attachment.sig>
Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74 https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/lli.cpp#L631 Best, Matt On 11/23/2017 19:49, Stefan Gränitz via llvm-dev wrote:> Maybe the easiest workaround would be overriding symbol resolution for > the function name and redirect it to your own version in static code > (and hope it has no bad side effect on your use case). > > I think when running 3rd party code, the only way to definitely avoid > this kind of trouble is to never deallocate any code or data sections. > Doug Binks mentioned that too in his cppcast about Runtime Compiled > C++ http://cppcast.com/2016/05/doug-binks/ > > Am 21.11.17 um 14:20 schrieb Nikodemus Siivola via llvm-dev: >> Transform the atexit into equivalent code you can control, run it >> before the destructors of the JIT engine run? >> >> >> On Tue, Nov 21, 2017 at 12:13 PM, Alex Denisov via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> > It's not the job of the Orc engine. >> >> I could argue about this, but I won’t :) >> >> > Just don't use atexit. >> >> The problem is that I run third-party programs. I cannot control >> them. >> >> > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> > >> > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via >> llvm-dev wrote: >> >> JIT allocates and maps some memory for the execution. Some >> function X at address 0xdeadbeef is part of this memory. >> >> JIT calls a code that passes the X to atexit. >> >> JIT deallocates and unmaps the memory used for execution >> (either via objectLayer.removeObjectSet or by calling JIT's >> destructors) >> >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which >> does not belong to 'us' anymore, which leads to the crash. >> > >> > Sounds plausible. >> > >> >> Given that my assumption is correct what can we do about this? >> Is there >> >> anything that can be done to cover this case inside of the Orc >> engine? >> > >> > It's not the job of the Orc engine. Just don't use atexit. >> > >> > Joerg >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > https://weliveindetail.github.io/blog/ > https://cryptup.org/pub/stefan.graenitz at gmail.com > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171123/f6c4c0c5/attachment.html>
Thank you all for your input and your ideas. Matt, this is very helpful. I used to do very similar thing myself, I’m glad that I can replace my code with class. I am now curious whether we can include _at_exit into LocalCXXRuntimeOverrides or it should go into another place? Lang, what do you think?> On 23. Nov 2017, at 22:15, Matt P. Dziubinski <matdzb at gmail.com> wrote: > > Hi, > > Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: > > https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74 > https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/lli.cpp#L631 > Best, > Matt > > On 11/23/2017 19:49, Stefan Gränitz via llvm-dev wrote: >> Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). >> >> I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime Compiled C++ http://cppcast.com/2016/05/doug-binks/ >> >> Am 21.11.17 um 14:20 schrieb Nikodemus Siivola via llvm-dev: >>> Transform the atexit into equivalent code you can control, run it before the destructors of the JIT engine run? >>> >>> >>> On Tue, Nov 21, 2017 at 12:13 PM, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> > It's not the job of the Orc engine. >>> >>> I could argue about this, but I won’t :) >>> >>> > Just don't use atexit. >>> >>> The problem is that I run third-party programs. I cannot control them. >>> >>> > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> > >>> > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote: >>> >> JIT allocates and maps some memory for the execution. Some function X at address 0xdeadbeef is part of this memory. >>> >> JIT calls a code that passes the X to atexit. >>> >> JIT deallocates and unmaps the memory used for execution (either via objectLayer.removeObjectSet or by calling JIT's destructors) >>> >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which does not belong to 'us' anymore, which leads to the crash. >>> > >>> > Sounds plausible. >>> > >>> >> Given that my assumption is correct what can we do about this? Is there >>> >> anything that can be done to cover this case inside of the Orc engine? >>> > >>> > It's not the job of the Orc engine. Just don't use atexit. >>> > >>> > Joerg >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-dev at lists.llvm.org >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> -- >> >> https://weliveindetail.github.io/blog/ >> https://cryptup.org/pub/stefan.graenitz at gmail.com >> >> >> _______________________________________________ >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171204/1b354848/attachment-0001.sig>