Improve LLDB's handling of non-local minidumps
authorLeonard Mosescu <mosescu@google.com>
Wed, 18 Apr 2018 23:10:46 +0000 (23:10 +0000)
committerLeonard Mosescu <mosescu@google.com>
Wed, 18 Apr 2018 23:10:46 +0000 (23:10 +0000)
commit47196a25bbec1d56961a1caf3e68410ee6aa93b5
treec19e0b0754f23a8737034b3d282653adec11fe12
parentcb80a3fce0708d48f50606b0203b2dc0326270bc
Improve LLDB's handling of non-local minidumps

Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory address ranges. In order to build the module and
section map LLDB tries to locate the local module image (object file)
and will parse it.

This does not work for postmortem debugging scenarios where the crash
dump (minidump in this case) was captured on a different machine.

Fortunately the minidump format encodes enough information about
each module's memory range to allow us to create placeholder modules.
This enables most LLDB functionality involving address-to-module
translations.

Also, we may want to completly disable the search for matching
local object files if we load minidumps unless we can prove that the
local image matches the one from the crash origin.
(not part of this change, see: llvm.org/pr35193)

Example: Identify the module from a stack frame PC:

Before:
  thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
    frame #0: 0x00164d14
    frame #1: 0x00167c79
    frame #2: 0x00167e6d
    frame #3: 0x7510336a
    frame #4: 0x77759882
    frame #5: 0x77759855

After:
  thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
    frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
    frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
    frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
    frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll
    frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll
    frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll

Example: target modules list

Before:
error: the target has no associated executable images

After:
[ 0] C:\Windows\System32\MSVCP120D.dll
[ 1] C:\Windows\SysWOW64\kernel32.dll
[ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
[ 3] C:\Windows\System32\MSVCR120D.dll
[ 4] C:\Windows\SysWOW64\KERNELBASE.dll
[ 5] C:\Windows\SysWOW64\ntdll.dll

NOTE: the minidump format also includes the debug info GUID, so we can
fill-in the module UUID from it, but this part was excluded from this change
to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or
20 bytes, while the CodeView GUIDs are normally 24 bytes)

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

llvm-svn: 330302
lldb/packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
lldb/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Core/Module.cpp
lldb/source/Core/Section.cpp
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/source/Plugins/Process/minidump/ProcessMinidump.h