linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: linuxppc-dev@ozlabs.org
Subject: Re: alignment bugs in prom_init
Date: Fri, 03 Mar 2006 10:50:36 -0500	[thread overview]
Message-ID: <440865CC.7070607@smiths-aerospace.com> (raw)
In-Reply-To: <20060303135717.GA5707@suse.de>

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?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Hi Olaf,

The casting is 8-byte aligning the address because it is a 64 bit 
variable and it is frowned on (and on some processors, fatal) to have an 
8-byte variable misaligned (not on a 8 byte boundary).

In your example above, the variable is named "sp"... the sp is suppose 
to be on a 8 byte boundary per the EABI (quoted below... note that the 
ABI requires it to be on a 16 byte boundary):
----
The Stack Frame
Unlike the SVR4 ABI, the stack pointer (GPR1) shall maintain 8-byte 
alignment, from initialization through all routine calls and dynamic 
stack space allocation.
----
In the instance above, the proper solution (but I don't know if it is a 
realistic solution :-/) is to properly align the stack pointer on a 8 
byte boundary.  I also don't know if there are other, non sp variable, 
problems.  It sounds like the prom isn't 64 bit clean.  What are our 
options to make it 64 bit clean?

Disclaimer: Yeah, I know most PPCs handle misaligned longs, but that 
doesn't make it _right_ and it definitely doesn't make it efficient.

gvb

  parent reply	other threads:[~2006-03-03 16:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-03 13:57 alignment bugs in prom_init Olaf Hering
2006-03-03 14:39 ` Andreas Schwab
2006-03-03 15:27   ` Olaf Hering
2006-03-03 15:50 ` Jerry Van Baren [this message]
2006-03-03 16:14 ` Jerry Van Baren
2006-03-03 17:24   ` Olaf Hering
2006-03-03 16:52 ` [PATCH] Workaround gcc bug #26549 which causes pointers to be truncated Olaf Hering
2006-03-03 19:16   ` [PATCH] force stackpointer alignment in 64bit kernel Olaf Hering
2006-03-03 19:23     ` Olaf Hering
2006-03-03 19:29     ` Segher Boessenkool
2006-03-03 19:32       ` Segher Boessenkool
2006-03-03 20:09       ` Olaf Hering
2006-03-03 20:40         ` Olaf Hering
2006-03-03 23:23       ` Olaf Hering
2006-03-03 23:45         ` Paul Nasrat
2006-03-04  0:09         ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=440865CC.7070607@smiths-aerospace.com \
    --to=gerald.vanbaren@smiths-aerospace.com \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).