[llvm-bugs] [Bug 49172] New: linking go objects creates bogus sections

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49172

            Bug ID: 49172
           Summary: linking go objects creates bogus sections
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: COFF
          Assignee: unassignedbugs at nondot.org
          Reporter: jason at zx2c4.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 24522
  --> https://bugs.llvm.org/attachment.cgi?id=24522&action=edit
A collection of object files

Attached as objects.tar.xz are a collection of object files generated by the Go
compiler plus cgo (via clang 11.0.1), for Windows. The go build system invokes
clang and the go compiler to make a series of coff files. It then calls out to
clang to ask it to invoke lld to link these all together. Its invocation is
long, but I've managed to reduce the test case to something trivial.

This produces an executable with bogus sections that crashes on startup:

x86_64-w64-mingw32-clang *.o -o llvm.exe

However, using gcc/binutils, this invocation creates a working binary:

x86_64-w64-mingw32-gcc *.o -o gcc.exe

It looks like a lot of the section information is being discarded by LLD. The
crash happens because the code tries to write to data that should be writable
but is actually part of an executable .text segment, as though all of the go
code is being merged into a single RX region.

I suspect this might be a LLD bug. On the other hand, perhaps this is intended
behavior and there's just some magic flag that needs to be passed down to LLD
in order to link these objects properly. I'm not quite sure yet.

-- 
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/20210213/431d12d8/attachment-0001.html>