I think you missed the point. The issue isn't with i, j or k. In fact
they are not optimised away, as they are globals. That is the reason I
made them global in my little program. If you try that code, and use
objdump to look at the final linked result you will see both i and j are
assigned from location 0x200. That is the problem. i should be assigned
from 0x200, and j from somewhere higher in memory.
Regards,
Steve
Ricardo H. Wiggers wrote:
Hi.
Aren´t i, j and k being optimised out, since nothing is made with them?
Merry christmas to all. And happy new year as well.
Bye,
Ricardo
----- Original Message -----
From: "Steve Underwood" <ste...@coppice.org>
To: <mspgcc-users@lists.sourceforge.net>
Sent: Tuesday, December 24, 2002 1:41 PM
Subject: [Mspgcc-users] Initialisation code
I just noticed that RAM is not initialise properly at startup, when the
default startup code is used. It tries looping between __data_start and
_edata, but these are both pointing to the same location - the start of
RAM. If I compile something like:
#include <io.h>
int i;
int j;
int k;
int main(int argc, char *argv[])
{
extern int __data_start;
extern int _edata;
extern int _etext;
i = __data_start;
j = _edata;
k = _etext;
return 0;
}
and look at the code (eg with objdump) the location of __data_start and
_edata are both 0x200, although _edata should clearly be somewhere
higher. I think this is not a new problem, but I am suprised I haven't
noticed it before. I'm not clear if the intention is that _edata should
point to the end of RAM or the end of used RAM. The related _etext
symbol points to the end of the code, rather than the end of the code
space.
I looked at the files in binutils/binutils-2.11/ld/, but I don't really
understand the syntax that is used (and, yes, I'm too lazy to work it
out right now).
A happy Christmas to anyone that solves this...... Oh, lets be generous.
A happy Christmas to everyone. :-)
Regards,
Steve
