On 05/07/2014 10:54 PM, Tom Musta wrote:
On 5/7/2014 2:02 PM, Tom Musta wrote:
It feels like there is an endianness issue here but I have not yet been able
to put my finger on it.
OK ... after more thought and scribbling ... here is what I mean ....
Suppose I have a 64-bit value 0xa0a1a2a3a4a5a6a7 stored in guest memory and it
gets loaded into a GPR. If I follow the dump code and view all four
combinations
of guest/host big/little endian, I convince myself that the big endian guest
code writes the byte sequence 0xa0, 0xa1, 0xa2, ..., 0xa7 into the file. And
the little endian guest dumps contain the sequence 0xa7, 0xa6, ..., 0xa0.
This make sense ... the endianness indicated in the dump header and the
endianness of
the dump file layout are consistent, irrespective of the host endianness.
If I take this a step further and consider a 128-bit value
0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf
stored in guest memory and look at the AVR structure (via printf or debugger)
after doing
a 128-bit lvx load, I get the following:
+------+-------+------------------+------------------+---------------------+
| Host | Guest | avr.u64[0] | avr.u64[1] | file sequence |
+------+-------+------------------+------------------+---------------------+
| BE | BE | a0a1a2a3a4a5a6a7 | a8a9aaabacadaeaf | a0,...,a7,a8,...,af |
| LE | BE | a8a9aaabacadaeaf | a0a1a2a3a4a5a6a7 | a8,...,af,a0,...,a7 |
| BE | LE | a0a1a2a3a4a5a6a7 | a8a9aaabacadaeaf | a7,...,a0,af,...,a8 |
| LE | LE | a8a9aaabacadaeaf | a0a1a2a3a4a5a6a7 | af,...,a8,a7,...,a0 |
+------+-------+------------------+------------------+---------------------+
The last column represents how I think the proposed dump code will write bytes
to disk. Notice that if you invert the (64-bit) array elements, then the two
BE dumps look alike and the two LE dumps look alike. If you swap array u64
elements on LE hosts, and also swap on LE guests, then you get a byte sequence
that looks like a 128-bit integer in all cases.
Since we're dumping an ELF core dump the big question is what gdb wants
to load :)
Alex
