Unaligned 64-bits access on FreeBSD/powerpc

[Maxim Sobolev]

Never mind, I have identified and fixed the problem.

Thanks to everybody for help!

-Maxim

Maxim Sobolev wrote:
> 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
>