Code review: 64-bit processor can't handle 32-bit ppc minidumps
Mark Mentovai
interpret 32-bit ppc minidumps, because the MDRawContextPPC struct
winds up with extra padding when built in the 64-bit environment.
MDRawContextPPC is normally 1004 bytes, but we're finding it's 1008
bytes on amd64. The processor correctly detects this as an error and
refuses to process 32-bit ppc minidumps.
This patch just resets the padding for this struct only.
The alignment problem occurs because the float_save field naturally
occurs at byte offset 164 in MDRawContextPPC, which is 4-byte-aligned
but not 8-byte-aligned. Because float_save is a struct that includes
a 64-bit-wide type, it's naturally 8-byte-aligned on a 64-bit system,
so 4 bytes of padding are inserted before float_save. Changing the
alignment breaks binary compatibility (which is fine, because we're
changing it to fix binary compatibility with the native CPU) and also
potentially introduces alignment problems when accessing data in the
structure. Normal x86 (amd64) operations can tolerate misaligned
data, but not all CPUs can. If this ever becomes a problem, we'll
need to write code to access only aligned data and then infer struct
members, rather than accessing struct members directly.
Mark
Neal Sidhwaney
Thanks,
Neal
Mark Mentovai
> Looks good to me! When you say breaks binary compatibility, it's unclear to
> me where it's being broken? It seems like the natural alignment of a 32-bit
> processor must be mimicked no matter what kind of CPU the minidump-processor
> is running on. So it was an error to not manually specify the alignment
> when building on a 64-bit CPU started.
Yup, that's right. Sorry, what I wrote was kind of an aborted
half-thought: it breaks binary compatibility with the struct's natural
definition on 64-bit systems, but we don't care because we actually
want to read the struct as it would be written by a 32-bit ppc. That
struct with natural 64-bit alignment is meaningless.
Mark