<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 - [LLD][MIPS][FreeBSD] ld -b binary outputs objects with no ABI flags"
href="https://bugs.llvm.org/show_bug.cgi?id=43368">43368</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[LLD][MIPS][FreeBSD] ld -b binary outputs objects with no ABI flags
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>FreeBSD
</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>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>kevans@FreeBSD.org
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=22532" name="attach_22532" title="git(1) diff against our contrib tree">attachment 22532</a> <a href="attachment.cgi?id=22532&action=edit" title="git(1) diff against our contrib tree">[details]</a></span>
git(1) diff against our contrib tree
Our firmware kmod build is kind of funky, I think- we start off by linking
together an object from our binary blob:
$ ld.lld -b binary -m elf32btsmip_fbsd -r -d -o blob.fwo blob
We then build a stub module that uses _binary_blob_start/end and passes it
through our firmware(9) interface. We hit the following error when we go to
link the final .ko:
ld.lld: error: otusfw_init.o: ABI 'o32' is incompatible with target ABI 'n64
The problem is easy to spot:
$ readelf -a otusfw_init.fwo| egrep 'Class:|Flags:'
Class: ELF32
Flags: 0, mips1
lld assumes that no flags means n64, and none are set because we didn't have
any input files that we could have gleaned it from. BFD doesn't seem to set
flags, but I don't know that BFD was doing ABI check on all of the input
objects. Regardless, I propose the attached patch.
The attached patch, in the absence of input files to derive flags from, takes
it from the -m flag. The -m flag gives us enough to know which ABI we're
emulating, so we might as well apply them to the resulting blob to appease lld.</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>