|
Message
From: "Raymond Chow" <rchow@n...>
Date: Fri, 30 May 2003 23:58:45 -0700
Subject: FW: [openrisc] GCC problem
-----Original Message-----
From: Venko Baksa [mailto:vbaksa@n...]
Sent: Friday, May 30, 2003 10:39 AM
To: owner-openrisc@o...
Subject: Re: [openrisc] GCC problem
Thank you for your suggestion to use gcc-3.2.3. It helped, and my problem
was
solved but only in non-optimized mode (O0). With any optimization (levels 1,
2
or 3) turned on, system crashes and SP, FP, LR and PC registers get
corrupted.
Debugging and analyzing the assembly code for non-optimized and optimized
version
of the API where system usually crashes, I noticed that the difference is
how extensively
FP register is used for stack store/load operations when optimization is
turned off, and is
not used at all when optimization is on. I wonder why is this big difference
how FP is
used, and is there a some compiler option that can be used to fix this
problem?
Thank you,
Venko Baksa
Nimbus Wireless, Inc.
> -----Original Message-----
> From: owner-openrisc@o...
> [mailto:owner-openrisc@o...]On Behalf Of Matjaz Breskvar
> Sent: Tuesday, May 06, 2003 4:14 AM
> To: openrisc@o...
> Subject: Re: [openrisc] GCC problem
>
>
> * vbaksa@n... (vbaksa@n...) wrote:
> > During debugging a RTOS kernel I discovered that following statement
> > caused the Link Address Register R9[LR] to be set to 0. Because of this
> > kernel crashed.
> > RTOSTcbHigRdy = RTOSTcbPrioTbl[(y << 3) + RTOSUnMapTbl
> > [RTOSRdyTbl[y]]];
> >
> > To avoid this problem and to make the kernel work I split the previous
> > statement to following 3 statements:
> > i = RTOSRdyTbl[y];
> > t = (y << 3) + RTOSUnMapTbl[i];
> > RTOSTCBHighRdy = RTOSTCBPrioTbl[t];
> >
> > Local variables and global arrays used in both cases are as follow:
> > ULONG y, t, i; // Locals
> > ULONG RTOSRdyTbl[]; // Global array
> > ULONG RTOSUnMapTbl[]; // Global array
> > ULONG *RTOSTCBPrioTbl[]; // Global array
> >
> > I used following compiler options to build the kernel:
> > rtostest-O0.o: rtostest.c
> > or32-uclinux-gcc -g -O0 $? -c -o $@
> > rtostest-O2.o: rtostest.c
> > or32-uclinux-gcc -g -O2 $? -c -o $@
> >
> > I believe that cause of the problem is how the gcc compiler handles
> > multiple array indexing.
> > Would you look at this problem and suggest which compiler option to use
> > to avoid this kind of problems in the future.
>
> first i would suggest you try with gcc-3.2.3 (just added into
> cvs) and letting us know if it fixes your problem.
>
> p.
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003
>
>
>
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003
|
 |
Browse
