amccarth marked 2 inline comments as done.
amccarth added a comment.
> Instead of test/functionalities/minidump, I would probably call this
> test/functionalities/core-file/windows.
Hmm...
There is talk of (eventually) debugging minidumps on other platforms. Also
some crash capture tools can make minidumps, even on Mac and Linux hosts. I
could imagine you might also want to be able to debug a core file from a
non-Windows host on a Windows host. So core-file/windows could end up being
confusing/misleading in the long run.
How about
test/functionalities/crash_files/core-files
and
test/functionalities/crash_files/mini-dumps
?
================
Comment at: test/functionalities/minidump/TestMiniDump.py:29
@@ +28,3 @@
+ stop_description = thread.GetStopDescription(256);
+ self.assertTrue("0xc0000005" in stop_description);
+
----------------
zturner wrote:
> Do we not have a way to get the exception code?
Unfortunately, no.
It looks like you can, because the API has methods for getting extra values
associated with the stop reason (SBThread::GetStopReasonDataCount and
SBThread::GetStopReasonDataAtIndex), but no data about exceptions is not
plumbed through--the process plugins just generate a string description and
attach it to the stop reason. I spent quite a bit of time discovering this.
I would like to make the process plugins provide the information in a way that
makes it available through those APIs as a separate patch.
http://reviews.llvm.org/D12888
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
