[all-commits] [llvm/llvm-project] 34d9f9: [AddressSanitizer] Ensure only AllocaInst is passe...

Wed Feb 12 11:24:11 PST 2020

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 34d9f93977fb33e45f9ac09d0a12f41254ef8845
      https://github.com/llvm/llvm-project/commit/34d9f93977fb33e45f9ac09d0a12f41254ef8845
  Author: Vedant Kumar <vsk at apple.com>
  Date:   2020-02-12 (Wed, 12 Feb 2020)

  Changed paths:
    M llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
    A llvm/test/DebugInfo/X86/asan_debug_info.ll
    M llvm/test/Instrumentation/AddressSanitizer/debug_info.ll

  Log Message:
  -----------
  [AddressSanitizer] Ensure only AllocaInst is passed to dbg.declare

Various parts of the LLVM code generator assume that the address
argument of a dbg.declare is not a `ptrtoint`-of-alloca. ASan breaks
this assumption, and this results in local variables sometimes being
unavailable at -O0.

GlobalISel, SelectionDAG, and FastISel all do not appear to expect
dbg.declares to have a `ptrtoint` as an operand. This means that they do
not place entry block allocas in the usual side table reserved for local
variables available in the whole function scope. This isn't always a
problem, as LLVM can try to lower the dbg.declare to a DBG_VALUE, but
those DBG_VALUEs can get dropped for all the usual reasons DBG_VALUEs
get dropped. In the ObjC test case I'm looking at, the cause happens to
be that `replaceDbgDeclare` has hoisted dbg.declares into the entry
block, causing LiveDebugValues to "kill" the DBG_VALUEs because the
lexical dominance check fails.

To address this, I propose:

1) Have ASan (always) pass an alloca to dbg.declares (this patch). This
   is a narrow bugfix for -O0 debugging.

2) Make replaceDbgDeclare not move dbg.declares around. This should be a
   generic improvement for optimized debug info, as it would prevent the
   lexical dominance check in LiveDebugValues from killing as many
   variables.

   This means reverting llvm/r227544, which fixed an assertion failure
   (llvm.org/PR22386) but no longer seems to be necessary. I was able to
   complete a stage2 build with the revert in place.

rdar://54688991

Differential Revision: https://reviews.llvm.org/D74369

  Commit: d6e47a405a3481c9c40ebe1c339349c01c504bd6
      https://github.com/llvm/llvm-project/commit/d6e47a405a3481c9c40ebe1c339349c01c504bd6
  Author: Vedant Kumar <vsk at apple.com>
  Date:   2020-02-12 (Wed, 12 Feb 2020)

  Changed paths:
    M lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
    M lldb/test/API/lang/cpp/class-template-parameter-pack/main.cpp

  Log Message:
  -----------
  [lldb/TypeSystemClang] Supply trivial TypeSourceInfo to NonTypeTemplateParmDecl::Create

This fixes a UBSan error seen while debugging clang:

Member call on null pointer of type 'clang::TypeSourceInfo'

rdar://58783517

Differential Revision: https://reviews.llvm.org/D73808

  Commit: 7aabad131288a598c90903ae7d96383105ae3fc2
      https://github.com/llvm/llvm-project/commit/7aabad131288a598c90903ae7d96383105ae3fc2
  Author: Vedant Kumar <vsk at apple.com>
  Date:   2020-02-12 (Wed, 12 Feb 2020)

  Changed paths:
    M lldb/source/DataFormatters/StringPrinter.cpp
    M lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
    M lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string/TestDataFormatterLibcxxString.py
    M lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string/main.cpp

  Log Message:
  -----------
  [lldb/StringPrinter] Avoid reading garbage in uninitialized strings

This patch fixes a few related out-of-bounds read bugs in the
string data formatters. These issues have to do with mishandling of un-
initialized strings. These manifest as ASan exceptions when debugging a
clang binary.

The first issue was that the std::string formatter treated strings in
"short mode" with length greater than the size of the inline buffer as
valid.

The second issue was that the StringPrinter facility did not check that
a full utf8 codepoint sequence can be read from the buffer (i.e. there
are some missing range checks). I took the opportunity here to delete
some untested code that was meant to deal with invalid input and replace
it with fail-on-invalid logic ([1][2][3]). This means we'll give up on
formatting an invalid string instead of guessing our way through it.

The third issue is that StringPrinter did not check that a utf8 sequence
could actually be fully read from the string payload. This one is especially
tricky as we may overflow the buffer pointer while reading the sequence.

I also noticed that the std::string formatter would spew the raw version of
the underlying ValueObject when garbage is detected. I've changed this to
just print "Summary Unavailable" instead, as we do elsewhere.

I've added regression tests for these issues to
test/functionalities/data-formatter/data-formatter-stl/libcxx/string.

[1]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L136
[2]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L163
[3]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L357

rdar://59080026

Differential Revision: https://reviews.llvm.org/D73860

  Commit: 90a94c02fb243f0b49ee9933b0e8145147f84e32
      https://github.com/llvm/llvm-project/commit/90a94c02fb243f0b49ee9933b0e8145147f84e32
  Author: Vedant Kumar <vsk at apple.com>
  Date:   2020-02-12 (Wed, 12 Feb 2020)

  Changed paths:
    M lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp

  Log Message:
  -----------
  [lldb/LibCxx] Have ExtractLibcxxStringInfo return an Optional result, NFC

Differential Revision: https://reviews.llvm.org/D74018

Compare: https://github.com/llvm/llvm-project/compare/32aac2563763...90a94c02fb24