[llvm-bugs] [Bug 43368] New: [LLD][MIPS][FreeBSD] ld -b binary outputs objects with no ABI flags

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: kevans at FreeBSD.org
                CC: htmldeveloper at gmail.com, llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190920/2d28d8f4/attachment.html>