Path: chuka.playstation.co.uk!news From: Majik Newsgroups: scee.yaroze.freetalk.english Subject: Re: Ten bytes bug in gcc? Date: Wed, 15 Aug 2001 10:32:50 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 40 Message-ID: <3B7A41C2.B4C5098E@127.0.0.1> References: <01c124b1$16cc8cc0$LocalHost@pal-s-omnibook> <9lbdjv$ds71@www.netyaroze-europe.com> <01c1250d$76401bc0$501ce4d5@pal-s-omnibook> NNTP-Posting-Host: 213.199.144.166 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en I'm sure I've seen this behaviour on the version of gcc I use to compile for Yaroze, it is indeed an alignment issue, more with the MIPS cpu than anything else, global data needs to be 32 bits wide, so I suspect that changed your buffer to 12 bytes will sort everything out. Note that adding a dummy buffer of 2 bytes won't fix it, as that just creates a new buffer, rather than use the spare 2 bytes from the first buffer.. a quick diagram is in order. you had unsigned char mybuffer[10]; unsigned char dummy[2]; void main() { } as it comes out of the compiler it may well look like; mybuffer: [reserve 4 bytes] [reserve 4 bytes] [reserve 2 bytes] dummy: [reserve 2 bytes] main: [some code] the problem is, as far as I remember, is that neither of the labels dummy: or main: occur on a 4 byte boundary, and the bug is that gas (the Gnu assembler) doesn't correct for this, and so the code produced will cause an execption for the MIPS cpu, which is expecting things to be 32bit aligned. M. pal wrote: > > Mmh... I'll try that, but what will be the explanation? > > Jon Prestidge (Jon@surfed.to) wrote in article > <9lbdjv$ds71@www.netyaroze-europe.com>... > > Have you tried test as 8, 16 and 512 characters?