workspace structure

[Catalin Morosan]

The workspace structure from my last mail was after looking at the rtems 
4.6.6 source code. So I guess rtems 4.6.6 allocates memory from the end 
of a free block...

Joel Sherrill wrote:
> Catalin Morosan wrote:
>> Hi.
>>
>> I've been trying to understand what exactly is the structure of the
>> workspace in memory, especially where are the information for the
>> threads and where are the stacks kept. I understand that the workspace
>> is allocated at the end of the memory and is like a separate heap.
>>
>> After doing some debugging of an application with 4 tasks I deduced 
>> this:
>>
>> ---beginning of workspace
>> ...
>> Task 4 stack
>> Task 3 stack
>> Task 2 stack
>> Task 1 stack
>> Task idle stack
>> ..
>> Task 1 control block
>> Task 2 control block
>> Task 3 control block
>> Task 4 control block
>> Task idle control block
>> ..
>> --- end of workspace
>>
>> Is this accurate?
>>   
> I don't think it is 100% accurate even ignoring the ...'s
>
> First in older RTEMS versions, the heap allocated memory
> from the end of a free block -- now it does it from the beginning
> of a free block so there is a chance of realloc() working.
>
> Each class of control block is allocated as a contiguous
> array.  So your task 1..4 CB's are contiguous.
>
> Internal tasks such as IDLE are allocated first so (in current
> RTEMS), the IDLE TCB address will be lower than the first
> Classic API task.  See this I printed by breaking at Init
>
> (gdb) p _Thread_Executing
> $1 = (Thread_Control *) 0x7dc2e8
> (gdb) p _Thread_Idle
> $2 = (Thread_Control *) 0x7dc148
>
> Notice IDLE is lower than Init (Classic API task 1)
>
> The stacks are not allocated until the task is created which
> (except for IDLE) is potentially long after RTEMS is initialized.
> Again in gdb at the same point.
> (gdb) p _Thread_Executing->Start.Initial_stack.area
> $4 = (void *) 0x7df2c0
> (gdb) p _Thread_Idle->Start.Initial_stack.area
> $5 = (void *) 0x7dcd48
>
> IDLE's stack was allocated before  the Classic API init task.
>
> The layout of Workspace memory is strictly a function of the
> order of initialization inside RTEMS and the order in which
> your application creates object such as tasks (stacks) and
> message queues (buffers).
>
> In summary, the only thing vaguely guaranteed is that the
> control blocks for objects within a single class were
> allocated as an array.
>> Also, I don't understand why it has this structure because
>> _Workspace_Allocate() takes only the size of memory to be allocated and
>> in turn, it calls _Heap_Allocate() with the size and the information for
>> the workspace. Doesn't allocation start from the beginning of the
>> workspace and continues to the end? Why is the task idle control block
>> after the control blocks of the other tasks although the idle task is
>> created first? etc. There is something I am missing but I can't see it
>> right now.
>>
>>   
> All control blocks are allocated then the stacks are
> allocated as the TCBs are used.
>
> For all non-system tasks, the TCB is allocated during init and
> the stack is allocated at create time so they are not even
> close to contiguous in memory.
>> Thanks for any input.
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>
>