Unaligned 64-bits access on FreeBSD/powerpc
Maxim Sobolev
sobomax at FreeBSD.org
Thu Aug 3 22:17:23 UTC 2006
David Edelsohn wrote:
>>>>>> Peter Grehan writes:
>
>>> atype = "64";
>>> for (i = 0; i < 256; i++) {
>>> apoint = (uint8_t *)&(buf[i]);
>>> v64 = *(uint64_t *)apoint;
>>> }
>
> Peter> Would you be able to do a disassembly on this ? I suspect gcc is using
> Peter> floating-point regs to do the 64-bit loads.
>
> That does not matter. The OS is suppose to catch the misaligned
> load and emulate the instruction in a handler. If FreeBSD cannot handle
> that, then it needs to configure GCC for PowerPC in strict-alignment
> embedded mode, which is ABI incompatible. If FreeBSD wants to use the
> standard PPC SVR4 ABI or PPC32 Linux variant, it must support any
> misaligned load. That is the OS's responsibility, period.
David,
Thank you for your input. I am trying to debug this problem right now.
It appears that the FreeBSD kernel already handles this condition based
on the DSISR/DAR contents(trap.c, function fix_unaligned()). However,
for some reason when the trap happens the DSISR is set to 0x40000000
(all bits but bit 30 are set to 0).
IBM's Programming Environments Manual says the following regarding
Alignment Exception in the big endian mode:
<quote>
Setting the DSISR and DAR as described below is optional for
implementations on which alignment exceptions
occur rarely, if ever, for cases that the alignment exception handler
emulates. For such implementations,
if the DSISR and DAR are not set as described below they are set to
undefined values.
</quote>
Therefore, I am wondering if it's the case here.
-Maxim
More information about the freebsd-ppc
mailing list