This is an archive of the discontinued LLVM Phabricator instance.

Implement register context for mini dump debugging
ClosedPublic

Authored by amccarth on Nov 11 2015, 2:55 PM.

Details

Summary

The old RegisterContextWinMiniDump stub is replaced with x86 and x64 implementations that derive from the common windows register contexts.

ProcessWindowsMiniDump grabs the WinAPI CONTEXT for each thread and stashes it in the thread object when building the thread list. The threads create the register context, stuffing in the saved CONTEXT.

New test ensures we can see the stack and registers for the (single) frame in the fizzbuzz minidump. (No variables or function names, since that inferior doesn't have DWARF information.)

You might also notice that I remove the thread names for MiniDump threads. Thread names are unavailable when port-mortem debugging Windows apps (since naming the thread requires having the debugger catch a special exception raised while the inferior is running).

Diff Detail

Repository
rL LLVM

Event Timeline

amccarth updated this revision to Diff 39978.Nov 11 2015, 2:55 PM
amccarth retitled this revision from to Implement register context for mini dump debugging.
amccarth updated this object.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.
zturner added inline comments.Nov 12 2015, 8:48 AM
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
40 ↗(On Diff #39978)

I remember us being able to get call stacks higher than main. But now that I think about it I guess that's only true for live debugging since you have a physical copy of the module loaded in your process, and you can read it's EAT. In any case, this assumption probably won't be true anymore once we understand PDBs and symbol servers. Although at that point hopefully we'll have many more tests covering different scenarios.

45 ↗(On Diff #39978)

Does this work if you change eip to pc? If so that would allow this test to work in the presence of 64 bit.

source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
193 ↗(On Diff #39978)

Can you change this to

auto thread_sp = llvm::make_shared<ThreadWinMiniDump>(*this, mini_dump_thread.ThreadId);
source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.h
42–44 ↗(On Diff #39978)

Why does this class need a separate CONTEXT than the one that is already stored in m_reg_context_sp? It seems like now we're storing the CONTEXT twice.

source/Plugins/Process/Windows/MiniDump/x64/RegisterContextWindowsMiniDump_x64.h
14 ↗(On Diff #39978)

Instead of using relative paths, I think you can write this as

#include "Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.h"
amccarth marked 3 inline comments as done.Nov 12 2015, 10:08 AM
amccarth added inline comments.
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
40 ↗(On Diff #39978)

Yes, I recognize that this will need to change when we have more debug info available. but it's sufficient for testing at this point.

45 ↗(On Diff #39978)

Indeed, "pc" works, so I'll use that.

source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.h
42–44 ↗(On Diff #39978)

Because the register context isn't created right away. It's lazily created later by this object, so this object needs a handle to it. Note that the CONTEXT in the Data is just a pointer, so it's not actually a second copy.

The process object pulls the original CONTEXT from the mini dump, and it creates this thread object. This thread object will later be called to create the register context object, so it has to keep track of the CONTEXT in order to do that.

zturner accepted this revision.Nov 12 2015, 1:10 PM
zturner edited edge metadata.
This revision is now accepted and ready to land.Nov 12 2015, 1:10 PM
This revision was automatically updated to reflect the committed changes.
amccarth marked an inline comment as done.
lldb/trunk/source/Plugins/Process/Windows/MiniDump/RegisterContextWindowsMiniDump.h