On Thu, Mar 11, 2010 at 02:26:29PM +0000, Martin Guy wrote:
> On 3/11/10, Martin Guy <martinwguy@gmail.com> wrote:
>
> > You can test for that by going
> > # echo 5 > /proc/cpu/alignment
> > and running your test again. On unaligned access the program will then
> > die with SIGBUS instead of merrily going on its way with corrupted
> > values.
>
> Note that QEMU does not emulate either the unaligned data corruption
> on /proc/cpu/alignment=0 nor the bus error on /proc/cpu/alignment=5;
> it always (on x86) performs a fixup, fetching in the "usual" way from
> *p to *[p+3], presumably because it compiles to an x86 word fetch.
> Real hardware is needed to test for word alignment errors.
Thanks, this is very good info, because I can replicate this under QEMU.
This means it's not an unaligned access issue, but something else.
I also tried two compiler versions, 4.4 (4.4.3-1) fails unittests but 4.3
(4.3.4-6) passes them.
While trying to debug this under gcc 4.4, I managed to add some code to an
inlined function that makes the problem go away. Original function version:
inline int64 WireFormatLite::ZigZagDecode64(uint64 n) {
return (n >> 1) ^ -static_cast<int64>(n & 1);
}
I wanted to add some ugly logging to the function, so I modified it as
follows:
inline int64 WireFormatLite::ZigZagDecode64(uint64 n) {
int64 v = (n >> 1) ^ -static_cast<int64>(n & 1);
printf("zzd64:%llu r:%lli\n", n, v);
return v;
}
It seems this changes something, because now the unittests pass (inline,
optimization, problems?). I honestly don't know what's happening here,
but this seems more and more like some compiler-related issue (but not
necessarily 64-bit-related).
iustin
Attachment:
signature.asc
Description: Digital signature