Add MinidumpContextWriter::CreateFromSnapshot(), everything downstream, and its test

Add MinidumpContextWriter::CreateFromSnapshot(), everything downstream,
and its test.

Minidump context structures now interoperate more easily with snapshot
CPUContext structures, while maintaining identical layout to before.
This is facilitated by reusing the Fxsave types for the substructures
which were completely identical, and by using compatible logic to
initialize the minidump and snapshot structures for testing.

TEST=minidump_test, snapshot_test
R=rsesek@chromium.org

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/52c2f6edfcc70cc61b1614dad34a7bd52100a5cf

[Mark Mentovai, 2014-10-30 17:12:58]

mark@chromium.org changed reviewers:
+ rsesek@chromium.org

[Mark Mentovai, 2014-10-30 21:41:37]

Patchset #3 (id:40001) has been deleted

[Robert Sesek, 2014-11-03 21:26:58]

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
File minidump/minidump_context_writer.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:79: context_.context_flags |=
kMinidumpContextX86All;
Why |= here? The other operations of this method all clobber data.

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:105: }
What about fxsave.xmm ?

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:152: context_.context_flags |=
kMinidumpContextAMD64All;
Same, why |= ?

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:155: context_.cs = context_snapshot->cs;
Why does Context have cs if it's supposed to be zero (like ds, es, and ss) in
64-bit mode, per IA3264 Vol. 1 §3.4.2.1? fs and gs make sense.

https://codereview.chromium.org/686353004/diff/80001/minidump/test/minidump_c...
File minidump/test/minidump_context_test_util.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/test/minidump_c...
minidump/test/minidump_context_test_util.cc:60: value += 2;  // Minidumps don’t
carry dr4 or dr5.
This comment may be useful in the header that defines this structure.

[Mark Mentovai, 2014-11-03 22:01:21]

Updated.

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
File minidump/minidump_context_writer.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:105: }
Robert Sesek wrote:
> What about fxsave.xmm ?

Doesn’t show up in context.float_save. I’ll add some clarifying commentary.

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:155: context_.cs = context_snapshot->cs;
Robert Sesek wrote:
> Why does Context have cs if it's supposed to be zero (like ds, es, and ss) in
> 64-bit mode, per IA3264 Vol. 1 §3.4.2.1? fs and gs make sense.

%cs is tricky. Your cited documentation says:

“In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0,
regardless of the value of the associated segment descriptor base. This creates
a flat address space for code, data, and stack.”

This refers to the base field of a segment descriptor. The segment registers
store offsets to a specific segment descriptor in a segment descriptor table,
not the segment descriptor itself. The layout of a segment descriptor is given
in volume 3A §3.4.5. The base is a 32-bit field within the segment descriptor.
Volume 1 §3.4.2.1 is just saying that regardless of what the segment descriptor
has in that position, the CPU will treat the base as 0, which forces all
addressing to be linear (non-segmented).

%cs is, however, still useful in the 64-bit environment. The L (“long”) bit of a
segment descriptor is what determines whether code executes in 32-bit or 64-bit
mode, and it is possible to transition between 32-bit and 64-bit-native code by
changing %cs to reference a segment descriptor formatted as desired. This is in
fact how the CPU makes the switch.

%ds, %es, and %ss become meaningless in 64-bit mode, because their contents
would have no impact on anything—there’s nothing in a segment descriptor that’s
relevant to them. %cs is different because it directly impacts how the CPU
interprets code.

You can also look for USER64_CS in xnu, which will show you where it’s
constructed, how it’s used, and the bug that doesn’t preserve the segment
registers other than %fs and %gs correctly through context switches.

https://codereview.chromium.org/686353004/diff/80001/minidump/test/minidump_c...
File minidump/test/minidump_context_test_util.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/test/minidump_c...
minidump/test/minidump_context_test_util.cc:60: value += 2;  // Minidumps don’t
carry dr4 or dr5.
Robert Sesek wrote:
> This comment may be useful in the header that defines this structure.

In addition or instead? I’m adding it there but leaving it here as a reminder of
why the += 2 is necessary.

[Robert Sesek, 2014-11-03 22:22:06]

LGTM

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
File minidump/minidump_context_writer.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:155: context_.cs = context_snapshot->cs;
On 2014/11/03 22:01:21, Mark Mentovai wrote:
> Robert Sesek wrote:
> > Why does Context have cs if it's supposed to be zero (like ds, es, and ss)
in
> > 64-bit mode, per IA3264 Vol. 1 §3.4.2.1? fs and gs make sense.
> 
> %cs is tricky. Your cited documentation says:
> 
> “In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0,
> regardless of the value of the associated segment descriptor base. This
creates
> a flat address space for code, data, and stack.”
> 
> This refers to the base field of a segment descriptor. The segment registers
> store offsets to a specific segment descriptor in a segment descriptor table,
> not the segment descriptor itself. The layout of a segment descriptor is given
> in volume 3A §3.4.5. The base is a 32-bit field within the segment descriptor.
> Volume 1 §3.4.2.1 is just saying that regardless of what the segment
descriptor
> has in that position, the CPU will treat the base as 0, which forces all
> addressing to be linear (non-segmented).
> 
> %cs is, however, still useful in the 64-bit environment. The L (“long”) bit of
a
> segment descriptor is what determines whether code executes in 32-bit or
64-bit
> mode, and it is possible to transition between 32-bit and 64-bit-native code
by
> changing %cs to reference a segment descriptor formatted as desired. This is
in
> fact how the CPU makes the switch.
> 
> %ds, %es, and %ss become meaningless in 64-bit mode, because their contents
> would have no impact on anything—there’s nothing in a segment descriptor
that’s
> relevant to them. %cs is different because it directly impacts how the CPU
> interprets code.
> 
> You can also look for USER64_CS in xnu, which will show you where it’s
> constructed, how it’s used, and the bug that doesn’t preserve the segment
> registers other than %fs and %gs correctly through context switches.

Acknowledged. Thanks for the details.

https://codereview.chromium.org/686353004/diff/80001/minidump/test/minidump_c...
File minidump/test/minidump_context_test_util.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/test/minidump_c...
minidump/test/minidump_context_test_util.cc:60: value += 2;  // Minidumps don’t
carry dr4 or dr5.
On 2014/11/03 22:01:21, Mark Mentovai wrote:
> Robert Sesek wrote:
> > This comment may be useful in the header that defines this structure.
> 
> In addition or instead? I’m adding it there but leaving it here as a reminder
of
> why the += 2 is necessary.

In addition, as you've done.

[Mark Mentovai, 2014-11-03 22:43:21]

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
File minidump/minidump_context_writer.cc (right):

https://codereview.chromium.org/686353004/diff/80001/minidump/minidump_contex...
minidump/minidump_context_writer.cc:155: context_.cs = context_snapshot->cs;
On 2014/11/03 22:22:06, Robert Sesek wrote:
> On 2014/11/03 22:01:21, Mark Mentovai wrote:
> > Robert Sesek wrote:
> > > Why does Context have cs if it's supposed to be zero (like ds, es, and ss)
> in
> > > 64-bit mode, per IA3264 Vol. 1 §3.4.2.1? fs and gs make sense.
> > 
> > %cs is tricky. Your cited documentation says:
> > 
> > “In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0,
> > regardless of the value of the associated segment descriptor base. This
> creates
> > a flat address space for code, data, and stack.”
> > 
> > This refers to the base field of a segment descriptor. The segment registers
> > store offsets to a specific segment descriptor in a segment descriptor
table,
> > not the segment descriptor itself. The layout of a segment descriptor is
given
> > in volume 3A §3.4.5. The base is a 32-bit field within the segment
descriptor.
> > Volume 1 §3.4.2.1 is just saying that regardless of what the segment
> descriptor
> > has in that position, the CPU will treat the base as 0, which forces all
> > addressing to be linear (non-segmented).
> > 
> > %cs is, however, still useful in the 64-bit environment. The L (“long”) bit
of
> a
> > segment descriptor is what determines whether code executes in 32-bit or
> 64-bit
> > mode, and it is possible to transition between 32-bit and 64-bit-native code
> by
> > changing %cs to reference a segment descriptor formatted as desired. This is
> in
> > fact how the CPU makes the switch.
> > 
> > %ds, %es, and %ss become meaningless in 64-bit mode, because their contents
> > would have no impact on anything—there’s nothing in a segment descriptor
> that’s
> > relevant to them. %cs is different because it directly impacts how the CPU
> > interprets code.
> > 
> > You can also look for USER64_CS in xnu, which will show you where it’s
> > constructed, how it’s used, and the bug that doesn’t preserve the segment
> > registers other than %fs and %gs correctly through context switches.
> 
> Acknowledged. Thanks for the details.

I think the AMD doc is a lot clearer on this. AMD 24593 rev.3.24 §4.5.3.

Technically, operating systems should save and restore all segment registers to
support programs that want to flip back to 32-bit mode on their own, because at
that point the segment registers do become relevant again. Mac OS X doesn’t do
this (but like I pointed out, it’s also got other bugs with these registers
during context switches). I don’t think Windows does either, but I do think
Linux does.

[Mark Mentovai, 2014-11-03 22:43:43]

Committed patchset #5 (id:100001) manually as
52c2f6edfcc70cc61b1614dad34a7bd52100a5cf (presubmit successful).