Path: chuka.playstation.co.uk!news
From: Majik <majik@127.0.0.1>
Newsgroups: scee.yaroze.freetalk.english
Subject: Re: Ten bytes bug in gcc?
Date: Thu, 16 Aug 2001 10:15:53 +0100
Organization: PlayStation Net Yaroze (SCEE)
Lines: 50
Message-ID: <3B7B8F49.3CBC7A2D@127.0.0.1>
References: <01c124b1$16cc8cc0$LocalHost@pal-s-omnibook> <9lbdjv$ds71@www.netyaroze-europe.com> <01c1250d$76401bc0$501ce4d5@pal-s-omnibook> <3B7A41C2.B4C5098E@127.0.0.1> <01c12570$15068c00$a708e4d5@pal-s-omnibook> <3B7A4B22.F0AB3595@127.0.0.1> <9le3jl$fio6@www.netyaroze-europe.com>
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

Right, I've done some more research on this (been a while since I did
any assembly)

it is, of course, the fact that the buffer size is not divisable by 4.
So anyone reading this
thread wondering what the probelm was can rest easy now.

Now I'll have a 2nd attempt at explaining what is going wrong.

Consider;

char mybuffer[10];
char dummy[2];
void main(void)
{
}

The problem is not, as I thought, the fact that this causes the code to
appear on unaligned boundaries,
in fact the code segment of the executable appears BEFORE the global
data sections! So what is going wrong.

Well it looks like it's a problem in libps, or which ever piece of code
it is that's responsible for
assigning the actual memory that mybuffer[] and dummy[] get compiled to.
When it get's compiled the data sections look like


mybuffer:
		.comm 10, 0
dummy:
		.comm 2, 0

these actually get compiled to different data sections (I assume because
one of them is unused) and that's why the extra 2 bytes doesn't fix
things - if it had been accessed then it probably would.

"Jon Prestidge (Jon@surfed.to)" wrote:
> By the way in CW there are some pragmas that you can use to force alignment
> at various points perhaps your compiler recognises them too -- they might be
> useful if you ever suspect the the compiler being incompetent.
Looking at the build options for gcc, I think you can make it do this
aswell. I don't know about anyone else but I'm using a build of gcc I
compiled on my Linux machine, targeted at mipsel-ecoff and so all the
alignment options (which I never touched) are probably still keyed to
x86, and as I mentioned earlier x86 still works on 8 bit units.
Whether or not there are pragmas to force the correct behaviour in gcc
remains to be seen.

M.