Add CaptureContext and its test

Add CaptureContext and its test.

TEST=client_test CaptureContextMac.CaptureContext
R=rsesek@chromium.org

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/be5d0ab39c96

[Mark Mentovai, 2014-08-20 01:10:25]

This is the heart of what Chrome’s DumpWithoutCrashing() will do.

[Robert Sesek, 2014-08-20 22:02:58]

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S
File client/capture_context_mac.S (right):

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:42: // affect %eflags.
In the x64 version you say at what offset this is going to be at on the stack.
I'd do that here too, and maybe on line 46 as well.

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:95: movl %edx, 40(%eax)  //
x86_thread_state->uts.ts32.__ss
Could you instead do |movzwl %ss, 40(%eax)| and not do the xor?

(As somewhat discussed offline, you can't use a segment register with movzwl, so
you'd still have to |movw %ss, %edx| so this isn't as nice as I thought it could
be).

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:140: movl $42, 4(%rdi)  //
x86_thread_state->tsh.count
Why is this 42 instead of 21? I'm guessing to account for the qwords instead of
dwords.

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:175: // %rsp was saved in %ebp in this function’s
prologue, but the caller’s %rsp
%rbp not %ebp

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:204: movq 8(%rdi), %rax
nit: blank line after

https://codereview.chromium.org/493563002/diff/1/minidump/minidump_module_wri...
File minidump/minidump_module_writer_test.cc (right):

https://codereview.chromium.org/493563002/diff/1/minidump/minidump_module_wri...
minidump/minidump_module_writer_test.cc:135:
EXPECT_EQ(static_cast<uint32_t>(expected_pdb_timestamp),
This is unrelated.

[Mark Mentovai, 2014-08-20 22:23:38]

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S
File client/capture_context_mac.S (right):

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:95: movl %edx, 40(%eax)  //
x86_thread_state->uts.ts32.__ss
On 2014/08/20 22:02:58, rsesek wrote:
> Could you instead do |movzwl %ss, 40(%eax)| and not do the xor?

I’d still need something to zero out the two bytes at 42(%eax) then.

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:140: movl $42, 4(%rdi)  //
x86_thread_state->tsh.count
rsesek wrote:
> Why is this 42 instead of 21? I'm guessing to account for the qwords instead
of
> dwords.

Exactly. All of the Mach *_COUNT values count machine-independent ints, which is
kind of dumb, but that’s how they work. (The machine-independent part isn’t
dumb, the use of an arbitrary unit that’s not a byte is.)

#define x86_THREAD_STATE32_COUNT        ((mach_msg_type_number_t) \
    ( sizeof (x86_thread_state32_t) / sizeof (int) ))

at least makes sense because all of the structure members are 32 bits wide, but

#define x86_THREAD_STATE64_COUNT        ((mach_msg_type_number_t) \
    ( sizeof (x86_thread_state64_t) / sizeof (int) ))

…oh well.

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:204: movq 8(%rdi), %rax
rsesek wrote:
> nit: blank line after

Why? The comment above the movq line applies to the popfq line just the same.
Compare this to lines 110 and 111 in the 32-bit x86 implementation.

https://codereview.chromium.org/493563002/diff/1/minidump/minidump_module_wri...
File minidump/minidump_module_writer_test.cc (right):

https://codereview.chromium.org/493563002/diff/1/minidump/minidump_module_wri...
minidump/minidump_module_writer_test.cc:135:
EXPECT_EQ(static_cast<uint32_t>(expected_pdb_timestamp),
rsesek wrote:
> This is unrelated.

Broken out.

[Robert Sesek, 2014-08-20 22:28:00]

LGTM

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S
File client/capture_context_mac.S (right):

https://codereview.chromium.org/493563002/diff/1/client/capture_context_mac.S...
client/capture_context_mac.S:204: movq 8(%rdi), %rax
On 2014/08/20 22:23:37, Mark Mentovai wrote:
> rsesek wrote:
> > nit: blank line after
> 
> Why? The comment above the movq line applies to the popfq line just the same.
> Compare this to lines 110 and 111 in the 32-bit x86 implementation.

Disregard.

[Mark Mentovai, 2014-08-20 22:30:23]

Committed patchset #2 manually as be5d0ab39c96 (presubmit successful).