On Thu, Oct 4, 2012 at 3:02 PM, R. Diez <[email protected]> wrote: > > >>> [...] > >>> At the moment, the stack is at the top of the RAM, which makes it hard to >> keep the RAM size flexible. >> >> Why not change the linker script to allocate a sane amount of memory >> space for stack and place this area after the data RAM? This then >> introduces a minimum RAM size that the executable is compatible with. >> Remember, this is just for libgloss-based executables, which are >> likely to be stand alone and not very big. > > I'm not certain what you mean by "data RAM" here. I haven't looked at the > libgloss files for a while, but I think the start-up code does not look at > any stack address specified in the linker script file, but just takes its own > hard-coded RAM size and places the stack pointer at the RAM's top end.
I meant section of the RAM that the linker uses for the data section. Basically, whatever is usually highest in memory. Perhaps it's BSS? Anyway, yes, we probably should be setting something reasonable in the linker script we're using and make the libgloss startup code use that. > > Furthermore, I generally dislike statements like "a sane amount of memory" > and "likely to be not very big" anyway. I would rather allocate a fixed > amount that libgloss needs to start up, and encourage the application or > Operating System to move the stack as soon as possible after newlib's own > startup, and maybe offer the possibility to reclaim the initial stack space > as malloc memory for the application. And I wouldn't want to make any > assumptions about how big the end application willl be. The whole point of my post was to suggest we allocate a fixed, not-insane amount of memory for the stack for the standalone apps which are likely to be using the libgloss startup code. OSes are not going to use the libgloss startup code are they? OSes may link against newlib, but they're going to have their own exception vector code, drivers etc. right? Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
