[llvm-bugs] [Bug 38248] New: lld crashing due to corrupt DefinedImportThunk

[via llvm-bugs]

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

            Bug ID: 38248
           Summary: lld crashing due to corrupt DefinedImportThunk
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: COFF
          Assignee: unassignedbugs at nondot.org
          Reporter: eric at andante.org
                CC: llvm-bugs at lists.llvm.org

I don't really have a good testcase, but I can describe the general sequence of
events.

I am linking a Windows application that links against dlls.  It creates
numerous DefinedImportThunk symbols, and this ultimately goes according to
plan.  But later on in the linking stage, includes an object file that also
defines one of the imported symbols, and it tries to fix this in this bit of
code:

Symbol *SymbolTable::addRegular(InputFile *F, StringRef N,
                                const coff_symbol_generic *Sym,
                                SectionChunk *C) {
  Symbol *S;
  bool WasInserted;
  std::tie(S, WasInserted) = insert(N);
  if (!isa<BitcodeFile>(F))
    S->IsUsedInRegularObj = true;
  if (WasInserted || !isa<DefinedRegular>(S)) {
    replaceSymbol<DefinedRegular>(S, F, N, /*IsCOMDAT*/ false,   <--- Here.
                                  /*IsExternal*/ true, Sym, C);
  } else
    reportDuplicate(S, F);
  return S;
}

This effectively tweaks the DefinedImportThunk symbol and changes it to a
DefinedRegular symbol.

The crash comes up at a later time in Writer::createImportTables(), where it
does this:

  for (ImportFile *File : ImportFile::Instances) {
    if (!File->Live)
      continue;

    if (DefinedImportThunk *Thunk = File->ThunkSym)
      Text->addChunk(Thunk->getChunk());                        <--- Here

    if (Config->DelayLoads.count(StringRef(File->DLLName).lower())) {
      if (!File->ThunkSym)
        fatal("cannot delay-load " + toString(File) +
              " due to import of data: " + toString(*File->ImpSym));
      DelayIdata.add(File->ImpSym);
    } else {
      Idata.add(File->ImpSym);
    }
  }

In particular, File->ThunkSym is no longer a DefinedImportThunk symbol, and
Thunk->getChunk() points to something completely unrelated.  This is what
ultimately causes the linker to crash.

In theory, one can add a check in Writer::createImportTables() to sanity check
ThunkSym.  While it prevents the crash, I have my doubts that this is a correct
fix.

-- 
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/20180720/c8dc8a83/attachment.html>