<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Link failure with LLVM gold plugin when embedded bitcode is involved for e.g. probe-stack symbol"
href="https://bugs.llvm.org/show_bug.cgi?id=47872">47872</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Link failure with LLVM gold plugin when embedded bitcode is involved for e.g. probe-stack symbol
</td>
</tr>
<tr>
<th>Product</th>
<td>tools
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>gold-plugin
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mh+llvm@glandium.org
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=24071" name="attach_24071" title="Testcase">attachment 24071</a> <a href="attachment.cgi?id=24071&action=edit" title="Testcase">[details]</a></span>
Testcase
Unzip the testcase (all files will extract in the current directory), and run
`make all -k`
This is reduced from
<a href="https://github.com/rust-lang/rust/issues/74657#issuecomment-668154580">https://github.com/rust-lang/rust/issues/74657#issuecomment-668154580</a>, with
added variants.
You'll see that main*.bfd, as well as main2.gold and main4.gold with `undefined
reference to 'probestack'`.
A little explainer of what's going on:
- we create:
- a main.o bitcode file that uses a "probestack" symbol as a probe-stack for
the `main` function.
- a probestack.o ELF file that contains both bitcode and machine code for a
dummy function.
- a probestack2_bc.o ELF file that contains the bitcode from probestack.o as
well as machine code with a different static function.
- a static library for each of the two probestack*.o files.
- we link main.o with each of probestack.o (main2), probestack2_bc.o (main4)
and their corresponding static library (main, main3), with each of BFD ld, gold
and lld.
The probestack2_bc variants are used as confirmation, on success, whether the
linker used the bitcode or the machine code. It turns out lld never uses the
machine code (per main3.lld and main4.lld containing `mov $0x2a,%eax`), and
gold doesn't use the machine code when it succeeds (per main3.gold containing
`mov $0x2a,%eax`).
What happens with BFD is that the bitcode for probestack is never compiled
during runLTO because an add_symbols call for the probestack object doesn't
happen until after runLTO has finished, during the inputs rescan
(`open_input_bfds (statement_list.head, OPEN_BFD_RESCAN);`)
This in turn seems to be due to the plugin not marking the probestack symbol as
being a requirement of main.o in the first place. If you add an explicit call
to `probestack()` in `main()`, it is marked as such, and all the link commands
succeed. It is worth noting that in that case, probestack is then compiled from
the bitcode for both bfd and gold (but not lld).
Note this problem also affects other symbols than the one used for the
probe-stack attribute. Symbols that are affected include e.g. __muloti4,
__mulodi4, __udivti3, etc. on x86, or __aeabi_uldivmod, etc. on armv7.
I am not 100% sure the problem lies on the plugin end, but from investigating
the issue and from the various results above, it seemed more likely, if not the
plugin itself, at least to be on LLVM's end.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>