[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: Use of r31 on the powerpc/booke:mpc85xx architecture
Yes, I was still using -fno-omit-frame-pointer when I experienced the issue,
perhaps it is responsible. I will try to reproduce shortly with different build
flags. Thank you for the response, I need to read the PPC ABI as I haven't yet
which is why I was unsure of the register allocations and googling got me the
incorrect answer the first time. Also I am not yet familiar with good practices
regarding gcc flags for the P2020 or more generally powerpc. Most of my time
has been spent on x86 and ARM thus far.
Understood wrt stmw/lwm, was misreading the inline assembly wrt counting colons
and PPC ASM wasn't fresh in my mind, context switch in progress ;)
From: Matt Thomas [mailto:matt%3am-software.com@localhost]
Sent: Thursday, September 06, 2012 6:44 PM
To: Scislowicz, Adam
Subject: Re: Use of r31 on the powerpc/booke:mpc85xx architecture
On Sep 6, 2012, at 5:11 PM, Scislowicz, Adam wrote:
> In sys/arch/powerpc/booke/booke_pmap.c:pmap_copy_page() The r31 register is
> used. When compiling for DDB support with "-fno-omit-frame-pointer" the
> compiler complains about the use of register 31. I am new to this
> architecture but it seems that register is used as the frame pointer.
Uh, why are you using that option? It's not really needed on powerpc.
> If you modify the inline assembly to use r23-r30 instead of r24-r31 it seems
> to solve the problem, but I wanted to ask if this is the right way to change
> this particular code as I am new to this architecture and don't want to
> introduce any unpredictable side effects when making the change locally.
Except that won't produce correct code since stmw/lwm will always save/restore
> It also seems that DDB support may not be functioning yet on the
> powerpc/booke architecture. Is this the known state of things with this port?
> I am using a P2020RDB-like system and using the P2020RDB config file which
> references the board code in mpc85xx. While the system otherwise works to
> some extent: I can boot and use user-space tools when not using DDB. However
> when I compile with DDB support I get a trap fairly early in the kernel
> initialization process and then my watchdog reboots the system from out of
> under me.
DDB works fine for me. What does it printout about the trap?
Are you still using -fno-omit-frame-pointer?
http://www.Taglocity.com Tags: netbsd-upstream
Main Index |
Thread Index |