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
next prev 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).