alignment bugs in prom_init

[Jerry Van Baren]

Olaf Hering wrote:
> Some G5 and pSeries models dont boot with recent kernels. The reason is
> likely the casting of pointers of stack variables to u32. One example is
> the prom_getprop() call in prom_init_stdout().
> 
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8. The firmware
> writes to the wrong addres and things go downhill very quick.
> 
> c00000000040baa8:       3b 21 00 78     addi    r25,r1,120
> ..
> c00000000040baf4:       57 28 00 38     rlwinm  r8,r25,0,0,28
> ..
> c00000000040bb10:       4b ff d3 3d     bl      c000000000408e4c <.call_prom>
> 
> If I remove the casts and pass the pointer as is, everything starts to
> work as expected? Why is all this (u32)(unsigned long) casting in
> arch/powerpc/kernel/prom_init.c required?
> 
> Does -Os vs -O2 make a difference here?

Hi Olaf, me again...

<http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/RS_002f6000-and-PowerPC-Options.html>

Looks like you should use -malign-natural to make it do what you want it 
to do:

-malign-natural
-malign-power
     On AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, the option 
-malign-natural overrides the ABI-defined alignment of larger types, 
such as floating-point doubles, on their natural size-based boundary. 
The option -malign-power instructs GCC to follow the ABI-specified 
alignment rules. GCC defaults to the standard alignment defined in the ABI.

     On 64-bit Darwin, natural alignment is the default, and 
-malign-power is not supported.

gvb