fix for Ruby build fails due to inlining functions with block label address taken

Gerolf Hoflehner ghoflehner at apple.com
Wed Jun 25 10:47:37 PDT 2014


Hi

there have been reports on Ruby segfaults triggered by inlining functions with block label address taken like


//Ruby code snippet
vm_exec_core() {
  finish_insn_seq_0 = &&INSN_LABEL_finish;
INSN_LABEL_finish:
  ;       
}     

This kind of scenario can also happen when LLVM picks a subset of blocks for inlining,
which is the case with the actual code in the Ruby environment.

Background:
LLVM suppresses inlining for such functions when there is an indirect branch. The attached
patch does so even when there is no indirect branch. Note that user code like above would not
make much sense: using the global for jumping across function boundaries would be illegal. 

Why is there a segfault:

In the snipped above the block with the label is recognized as dead. So it is eliminated. Instead 
of a block address the cloner stores a constant (sic!) into the global resulting in the segfault (when
the global is used in a goto).

Why did it work in the past then:

By luck. In older versions vm_exec_core was also inlined but the label address used
was the block label address in vm_exec_core. So the global jump ended up in the original function 
rather than in the caller which accidentally happened to work.


-Gerolf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140625/06dfe3b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Suppress-inlining-when-the-block-address-is-taken.patch
Type: application/octet-stream
Size: 3517 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140625/06dfe3b9/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140625/06dfe3b9/attachment-0001.html>


More information about the llvm-commits mailing list