https://bugs.llvm.org/show_bug.cgi?id=43368
Bug ID: 43368
Summary: [LLD][MIPS][FreeBSD] ld -b binary outputs objects with
no ABI flags
Product: new-bugs
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: kev...@freebsd.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 22532
--> https://bugs.llvm.org/attachment.cgi?id=22532&action=edit
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.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
