This is an archive of the discontinued LLVM Phabricator instance.

Add first tests for mini-dump debugging.
ClosedPublic

Authored by amccarth on Sep 15 2015, 2:40 PM.

Details

Summary

This includes a dump file captured using Visual Studio, of the enclosed sample program, which was also build with Visual Studio.

The tests just verify that LLDB can access some very basic information from the mini-dump.

Diff Detail

Event Timeline

amccarth updated this revision to Diff 34840.Sep 15 2015, 2:40 PM
amccarth retitled this revision from to Add first tests for mini-dump debugging..
amccarth updated this object.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.
zturner edited edge metadata.Sep 16 2015, 9:22 AM

Instead of test/functionalities/minidump, I would probably call this test/functionalities/core-file/windows.

I'm using core-file instead of minidump because it's the most generic term that will make sense on all platforms, and other platforms will essentially want to add tests for this. And I'm making a windows subdirectory because we're going to have enough of these eventually that we'll want to separate them.

test/functionalities/minidump/TestMiniDump.py
14

I think you can actually put this at the class level, then you don't need it on individual tests.

29

Do we not have a way to get the exception code?

39–41

This can go away

amccarth marked 2 inline comments as done.Sep 16 2015, 10:32 AM

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

?

test/functionalities/minidump/TestMiniDump.py
29

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.

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

?

Are the "mini dumps" you're referring to that can be created on a Mac or Linux host the same file format? I think we need some way to capture the distinction between the two file formats. All of the different formats have one thing in common though. They support *postmortem* debugging. So maybe it could be:

test/functionalities/postmortem/elf

test/functionalities/postmortem/windows

I don't think having it be called "windows" precludes being able to use the functionality on non-windows hosts (provided we ever write a library that can process them on non-Windows), I just can't think of a better way to describe the format itself.

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

?

Are the "mini dumps" you're referring to that can be created on a Mac or Linux host the same file format? I think we need some way to capture the distinction between the two file formats. All of the different formats have one thing in common though. They support *postmortem* debugging. So maybe it could be:

test/functionalities/postmortem/elf

test/functionalities/postmortem/windows

I don't think having it be called "windows" precludes being able to use the functionality on non-windows hosts (provided we ever write a library that can process them on non-Windows), I just can't think of a better way to describe the format itself.

Note that Breakpad uses the Windows minidump format for all platforms: https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad#The_minidump_file_format

So it makes sense to distinguish based on crash file type rather than platform. Thus, per offline discussion, we'll go with:

test/functionalities/postmortem/minidump

In the future, we can add tests for core files in:

test/functionalities/postmortem/core
amccarth updated this revision to Diff 34906.Sep 16 2015, 11:02 AM
amccarth edited edge metadata.

Addressed earlier comments and moved to functionalities\postmortem\minidump

This revision was automatically updated to reflect the committed changes.