Path: chuka.playstation.co.uk!news
From: Jim <jim@micronetics.com>
Newsgroups: scee.yaroze.programming.gnu_compiler
Subject: Re: Relatively Important(!) : Buggy gcc
Date: Mon, 28 Apr 1997 22:29:40 +0100
Organization: PlayStation Net Yaroze (SCEE)
Lines: 44
Message-ID: <336516C4.2958@micronetics.com>
References: <336635d6.3891193@news.playstation.co.uk>
NNTP-Posting-Host: jim.micronetics.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.0b2 (Win95; I)
X-Priority: 3 (Normal)

Alex Amsel wrote:
> 
> Bug 2
> ~~~~
> 
> anyway).  BOOL was defined as a UBYTE, which caused an error, then a
> UWORD which also caused an error.  In fact, only by defining it as
> ULONG did it work. But again, it only ever went wrong when certain
>
> 
> FIXEDPOINT is defined as an int BTW, and the array is global.
> 
> struct BloodPartical {
>         UWORD X, Y;
>         BOOL XNeg, YNeg;
>         FIXEDPOINT XPos, YPos;
>         FIXEDPOINT XVel, YVel;
>         FIXEDPOINT XAccl, YAccl;
>         ULONG PrevCol;
> };
> 


Alex,

 These ones can be a real bugger to find.  The r3000 is generating a bus
error when it tries to access any data after the 4th byte.  This occurs
when you access data on unaligned addresses.  It appears that gcc is not
padding the structure out.  The problem is caused by XNeg, YNeg both
being a byte each and unaligning the whole structure.

If gcc is not automatically padding the structures there should be a
pragma or a command line switch to do so.


Sony:  Can we have the exception vector addresses?  It would make life
so much easier if I could just dump BusError to the log if it goes belly
up rather than counting though map files or examining code, where infact
the fault does not lie .  You could also then roll the stack to find the
faulting address.  

Regards

Jim