Page MenuHomePhabricator

[llgo] Force exporting __morestack from llgoi
ClosedPublic

Authored by axw on Sep 3 2015, 8:08 PM.

Details

Summary

Force exporting morestack from llgoi, so that
the symbol is available to the execution engine
when linking with libLLVM.so. The engine does
not reference
morestack explicitly, so must
be provided by the host program.

Diff Detail

Event Timeline

axw updated this revision to Diff 34009.Sep 3 2015, 8:08 PM
axw retitled this revision from to [llgo] Force exporting __morestack from llgoi.
axw updated this object.
axw added a reviewer: pcc.
axw added a subscriber: llvm-commits.
pcc edited edge metadata.Sep 23 2015, 7:10 AM

Can you explain why the stuff in lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp doesn't help here?

axw added a comment.Sep 25 2015, 1:45 AM
In D12625#251706, @pcc wrote:

Can you explain why the stuff in lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp doesn't help here?

The problem is when ExceptionEngine is built as a shared library. In this case, libLLVMExecutionEngine.so (or libLLVM.so, as in my case) has a weak symbol reference to __morestack, rather than the main program having the weak symbol. That weak symbol reference is never resolved because neither llgoi nor libgo-llgo exports it.

Is there a better, more general solution? This feels a bit kludgey, but I'm not sure what else to do about it. Perhaps a mode in which ExecutionEngine can be compiled with a non-weak reference to __morestack?

pcc added a comment.Nov 3 2015, 6:01 PM

LGTM

Another solution would be to have LLVMExecutionEngine contain a strong reference to __morestack conditional on whether the symbol is found at configure time. That seems kind of bad as well, since we try to avoid adding new configure-time checks. Up to you on which way to go though.

pcc accepted this revision.Nov 3 2015, 6:01 PM
pcc edited edge metadata.
This revision is now accepted and ready to land.Nov 3 2015, 6:01 PM
axw closed this revision.Nov 26 2015, 8:49 PM