I found a problem when I'm building an SoC with or1200 core. My RAM is only 8MB, and when I run my program compiled with or32-elf-gcc(I built the newlib toolchain following http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29), I found the program want to access data in 0x007FFFFC�
I check the objdump result, and found the access for 0x007FFFFC is in "__impure_init" in section ".text". I don't know what "__impure_init" does and why it want to write to 0x007FFFFC. Is the stack mapped there?
The attachement is my program's objdump file.
//----------- my C code -----------
int main()
{
volatile int a;
while(1){
a++;
}
return 0;
}
//---------------------------------
BTW: How can I tell GCC to compile my program into the 8MB ram?

That __impure_init function is part of the newlib C code I believe:

https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/impure-init.c

After Googling I found this page which explains a little bit more:

http://embdev.net/topic/129813

From: http://andrewsterian.com/424/Lecture17.pdf�

I get the following:

"If you want to run multiple threads in your program AND you want yourprogram to be thread safe (this isn�t a 100% requirement!) then ...[y]ou must initialize the elements of the structure using the_REENT_INIT_PTR() macro defined in "reent.h"

so it's something to do with making newlib C code thread safe.

Why it's accessing that memory address, though, I don't know. But, the stack pointer is set to the top of memory by default in the newlib libgloss code:

https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/crt0.S#L258

... it takes the memory base, adds the memory size and puts that in r1 (the stack pointer).

So something in the _REENT_INIT_PTR(_impure_ptr) call is probably accessing the stack.

And the top of memory is at address 0x007ffffc with 8MB RAM,
so I'm not sure what's the problem?