[llvm-bugs] [Bug 45985] New: libcall symbol handling causes nullpointer dereference

[via llvm-bugs]

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

            Bug ID: 45985
           Summary: libcall symbol handling causes nullpointer dereference
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: COFF
          Assignee: unassignedbugs at nondot.org
          Reporter: thrimbor.github at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23506
  --> https://bugs.llvm.org/attachment.cgi?id=23506&action=edit
Stacktrace of the crash

https://reviews.llvm.org/D66355 introduced better handling of symbol references
that arise from code generation, and whose definitions reside in bitcode files
themselves.

Unfortunately, and I'm not sure why this happens, it also introduced crashes
when building for our Windows-like target platform, which, when using LTO, has
almost all of its code, including symbols usually provided by runtime
libraries, in bitcode files.

The combination of code relying on `__fltused` and/or `_chkstk` with the above
patch results in DefinedRegular::getChunk() dereferencing a nullpointer (member
variable called "data") when called from "enqueue(sym->getChunk());" in
"markLive". I've added some print statements in an attempt to debug this, and
this happened for two symbols:

1. "__fltused", which is emitted whenever floating point math is used. We
previously worked around this by adding  #pragma comment(linker,
"/include:__fltused") to the file where "__fltused" is defined. This does not
fix the issue though. The proper fix (and I've successfully tried this locally)
for this symbol is probably to include it in the list of libcalls.

2. "__xlibc_check_stack", which is a function (written in C and compiled to
bitcode) used by our custom implementation of "__chkstk" (written in assembly)
- this function does not exist on normal Windows platforms. I've tried to fix
this by adding a similar include pragma, to no success.

My current workaround for these is to add "-include:__xlibc_check_stack
-include:__fltused" to the linker invocation. This is however undesirable, as
we're trying to reduce the number of linker arguments our users have to be
concerned with.

So to summarize what I think will resolve this:
1. The nullpointer dereference should be caught (and the general behavior of
the linker producing regular symbols with an invalid chunk reference fixed, if
it is incorrect)
2. "__fltused" should be added to the list of libcall symbols
3. Include pragmas not having the same effect as command line arguments should
be fixed

-- 
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/20200518/a5147aad/attachment.html>