minidump_dump: Display x86 CPU vendor string for x86_64

minidump_dump: Display x86 CPU vendor string for x86_64

[Mark Mentovai]

The MS documentation is unclear and I haven’t had a chance to look at a genuine
Windows minidump, but for Linux and Mac dumps that we generate ourselves, we do
populate these x86 fields for x86_64, which makes sense because the bits and
meanings are all the same within the x86 family. (Do you know the answer on
Windows?)

I also haven’t seen MD_CPU_ARCHITECTURE_X86_WIN64 in the wild, which I expect
means that it’s used for 32-bit x86 code running on IA64, but not 32-bit x86
code running on x86_64.

[Ted Mielczarek]

On 2014/05/29 20:37:20, Mark Mentovai wrote:
> The MS documentation is unclear and I haven’t had a chance to look at a
genuine
> Windows minidump, but for Linux and Mac dumps that we generate ourselves, we
do
> populate these x86 fields for x86_64, which makes sense because the bits and
> meanings are all the same within the x86 family. (Do you know the answer on
> Windows?)

I wrote a test dump and it looks like MiniDumpWriteDump doesn't fill this in on
Win64. minidump_dump shows:
  cpu.x86_cpu_info.vendor_id[0]              = 0x7744
  cpu.x86_cpu_info.vendor_id[1]              = 0x0
  cpu.x86_cpu_info.vendor_id[2]              = 0x0

I suspect this means it's actually filling in the
other_cpu_info.processor_features side of the union.

Test dump is here if you want to poke at it:
http://people.mozilla.com/~tmielczarek/testx86-64.dmp

> I also haven’t seen MD_CPU_ARCHITECTURE_X86_WIN64 in the wild, which I expect
> means that it’s used for 32-bit x86 code running on IA64, but not 32-bit x86
> code running on x86_64.

Me either. Win32 apps running on WOW64 appear to just use
MD_CPU_ARCHITECTURE_X86. I suspect that was dropped in favor of backwards
compatibility.

[Mark Mentovai]

Ted Mielczarek wrote:
> I wrote a test dump and it looks like MiniDumpWriteDump doesn't fill this in
on
> Win64. minidump_dump shows:
>   cpu.x86_cpu_info.vendor_id[0]              = 0x7744
>   cpu.x86_cpu_info.vendor_id[1]              = 0x0
>   cpu.x86_cpu_info.vendor_id[2]              = 0x0
> 
> I suspect this means it's actually filling in the
> other_cpu_info.processor_features side of the union.
> 
> Test dump is here if you want to poke at it:
> http://people.mozilla.com/~tmielczarek/testx86-64.dmp

Thanks. I won’t be landing this patch, then. Perhaps we should change the
existing Linux and Mac dump writers to not populate these fields as they do for
x86 when they’re dumping for an x86_64 process. Your sample dump would be:

  cpu.other_cpu_info.processor_features[0]   = 0x7744
  cpu.other_cpu_info.processor_features[1]   = 0x0

which would be bits 2, 6, 8, 9, 10, 12, 13 and 14. I initially suspected that
this had to be wrong because PF_MMX_INSTRUCTIONS_AVAILABLE (3) doesn’t show as
available, but one of the comments at the bottom of
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724482(v=vs.85).aspx
says that MMX and 3DNow are reported as unavailable in 64-bit code.

> > I also haven’t seen MD_CPU_ARCHITECTURE_X86_WIN64 in the wild, which I
expect
> > means that it’s used for 32-bit x86 code running on IA64, but not 32-bit x86
> > code running on x86_64.
> 
> Me either. Win32 apps running on WOW64 appear to just use
> MD_CPU_ARCHITECTURE_X86. I suspect that was dropped in favor of backwards
> compatibility.

Excellent. Thanks for the confirmation. Since neither of us have ever seen these
dumps in the wild, I won’t worry about whether we should handle the system-info
stream for this phantom processor type as x86 or non-x86, and I’ll leave the
existing treatment as x86 alone.