Workspace in new style

Joel Sherrill joel.sherrill at
Thu Feb 11 15:47:57 UTC 2010

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....


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.

> 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        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the users mailing list