Breakpad Processor: Add new unit tests for google_breakpad::Minidump

This also adds two new test utility class groups, TestAssembler and
SynthMinidump. These are overkill for what I'm doing with them here
(and may simply be overkill, period), but they make it easy to write
unit tests for code that works on binary files or raw memory contents
in a cross-platform way. I'm planning to use them for the DWARF CFI
unwinding tests and the DWARF CFI parser tests.

[jimb]

A fresh version of this patch.  The TestAssembler classes are used later by the
DWARF CFI parser unit tests and the StackwalkerX86 unit tests.

[jimb]

Hi, just a ping on this one.

The title of this issue may suggest that it doesn't have dependencies, but
actually, all the unit tests in the later patches depend on the TestAssembler
classes added in this patch, so this patch needs to get taken care of before I
can commit anything else.

[mochalatte]

LGTM

http://breakpad.appspot.com/53001/diff/2001/18
File src/processor/synth_minidump_unittest_data.h (right):

http://breakpad.appspot.com/53001/diff/2001/18#newcode3
Line 3: // Not copyrightable: random test data.
when you say random test data, i assume the data is still actually valid in the
sense that processor state registers might still require certain bit patterns -
is that the case for this data or is actually completely random?

http://breakpad.appspot.com/53001/diff/2001/19
File src/processor/test_assembler.cc (right):

http://breakpad.appspot.com/53001/diff/2001/19#newcode148
Line 148: //   l = m, m = n, n = l;
from the test coverage, i assume this generalizes to a loop of any length(maybe
it could be clarified in the comment)

[jimb]

Hi, Neal.  Thanks for the review.  I'm going to go ahead and land this; if
you're concerned about the random test data, let's open a separate bug for that.

http://breakpad.appspot.com/53001/diff/2001/18
File src/processor/synth_minidump_unittest_data.h (right):

http://breakpad.appspot.com/53001/diff/2001/18#newcode3
Line 3: // Not copyrightable: random test data.
No, it's really random.  For the sake of this test, what we want to know is
whether the reader accurately conveys the contents of the file.  I don't think
validation of the contents is part of the minidump reader's contract; if it is,
then the tests should be changed.

http://breakpad.appspot.com/53001/diff/2001/19
File src/processor/test_assembler.cc (right):

http://breakpad.appspot.com/53001/diff/2001/19#newcode148
Line 148: //   l = m, m = n, n = l;
On 2010/03/03 22:26:09, mochalatte wrote:
> from the test coverage, i assume this generalizes to a loop of any
length(maybe
> it could be clarified in the comment)

I've expanded the comment.

[jimb]

Committed, r547.