Workspace in new style

[Joel Sherrill]

On 02/11/2010 02:43 AM, Leon Pollak wrote:
> Thanks, Joel.
>
> I understood now the source of my error:
> My 4.8.0 based application was satisfied with 128KiB for workspace.
> Now, the new 4.10 based version requires 312KiB for the same workspace!
> I did not suppose that almost thrice request comes from RTEMS needs and
> thought that I have some configuration problem.
>
> Now, is it normal that 4.10 requires so much room?
>
>    
In a word, no. :D

Is this the same application configuration?  Could you post
your set of configuration directives?

Or if you want to see what else is new....

#define CONFIGURE_CONFDEFS_DEBUG

That instantiates a few structures which contain various
computed space requirements that are added together
to get the workspace size required.  In gdb, print
Configuration_Debug_t and Configuration_Memory_Debug.

You don't even have to download the executable to target
hardware to accomplish this.  So far, every time I wanted to
see this, I could load the elf into the cross gdb and just
print those structures.

--joel
> Thanks!
>
> On Wednesday February 10 2010, Joel Sherrill wrote:
>    
>> On 02/10/2010 06:13 AM, Leon Pollak wrote:
>>      
>>> Hello, all.
>>>
>>> I am trying to debug the new style BSP (with all this new unified stuff).
>>> And I failed to understand the following:
>>> The bsp_get_work_area function defines the workarea start and size.
>>> But then it is checked against the Configuration table, which has its own
>>> value for size (as minimum, may be for something else too, did not find
>>> yet). In my case the check fails, so what am I supposed to do?
>>>        
>> The Configuration.work_space_size field is the amount of
>> memory calculated by confdefs.h that will be required for
>> the configured set of objects.  If there is not enough
>> memory, then there is a common failure path in
>> bootcard.c now.  Take a look at libbsp/shared/bootcard.c
>> and see how much better this code is now.  You have been
>> around long enough to (I hope) appreciate how much is
>> in here that used to be in individual BSPs.  And how much
>> clearer the initialization process is now.
>>
>> Previously this error was detected (or not)
>> and handled in BSP specific ways.  This is just one area
>> that significantly improved with the rework that
>> was needed to support the option of unified work area.
>>
>> FWIW when using unified, you may also be limited in
>> the unlimited object support added years ago by Chris
>> Johns.
>>
>>      
>>> Thanks a lot for clarification.
>>>        
>>      


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985