ERC-32 RTEMS Stack Overflow?

[steved94]

Silly question, but have you tried something along the lines of:

 TASK TYPE Solution_Process IS
    PRAGMA Storage_Size( 524_288 );
    ENTRY Start;
  END Solution_Process;

This is not a GNAT/RTEMS answer, but rather a straight Ada answer (I haven't
tried it).

SteveD

----- Original Message -----
From: "Alan Brain" <abrain at auspace.com.au>
To: <rtems-users at oarcorp.com>
Sent: Wednesday, November 14, 2001 2:30 PM
Subject: RE: ERC-32 RTEMS Stack Overflow?


> G'day to one and all.
>
> For my sins, I'm leading the spaceflight software development team
> on the Australian FedSat microsatellite programme. Although it's
> only a 50 kg satellite, it has 5 experiments on board, so has a
> fairly complex set of software. CPU is an ERC-32. Compiler is
> GNAT 13.11p with RTEMS.
>
> We've been having some problems which appear to be due to a systemic
> stack overflow problem. Basically,
>
> package body Foo is
>
>    procedure Bar is
>       some_local : a_large_data_structure_T; -- will be put on stack?
>    begin
>       do_stuff;
>    end Bar;
>
> end Foo;
>
> will cause problems somewhere in the system, a task will die,
> or a memory error will occur, usually in a part of the program
> remote from the cause.
>
> If we change to
>
> package body Foo is
>
>    used_to_be_some_local : a_large_data_structure_T; -- not on stack?
>
>    procedure Bar is
>    begin
>       do_stuff;
>    end Bar;
>
> end Foo;
>
> Then the problem goes away.
>
> It appears that if a_large_data_structure_T'SIZE is >256*8 the
> problem occurs, but we have been too busy working around the
> problem to investigate it.
>
> Questions to the list:
> a) Has this been noted before? If so, where can I find doco on it?
> b) Is there a patch (to GNAT or RTEMS) that gets around it?
>
> We strongly suspect that it's a stack corruption problem due to the
> use of the ERC-32/Spark's hardware method for detection of stack end,
> where if I understand it correctly there's a 256-byte magic marker
> inserted at end-of-stack. So allocation of a large data object (>256
bytes)
> will completely blow this and cause over-run into memory parts unknown.
>
> Or it could be something else entirely. Comments, please?
>