[ECOS] finding out what's taking space in .bss

[Jonathan Larmour]

heinricg@esiee.fr wrote:
> 
>>for the HAL to link in a function that is called in the idle
>>thread. This could for example change the power saving of the
>>processor. Such a function needs some stack space. For "normal"
>>systems 1k does not count, so 1k seems a reasonable default.
>>
> 
> 
> the funny thing is CYGNUM_THREADS_IDLE_STACK_SIZE is set to 512 in the
> configuration tool, I have SMP support turned off, and there are 1120
> bytes between idle_thread_stack and the next symbol. Did I read the
> map incorrectly?

No, there is some jiggery pokery in kernel/current/src/common/thread.cxx 
which makes sure the stack size is at least CYGNUM_HAL_STACK_SIZE_MINIMUM. 
This figure is meant to be the absolute minimum a thread (like the idle 
thread) could get away with, due to potentially needing to handle 
interrupts on that stack or not.

In the ARM HAL for example:
// A minimal, optimized stack frame, rounded up - no autos
#define CYGNUM_HAL_STACK_FRAME_SIZE (4 * 20)

// Space for the maximum number of nested interrupts, plus room to call 
functions
#define CYGNUM_HAL_MAX_INTERRUPT_NESTING 4

// Interrupt + call to ISR, interrupt_end() and the DSR
#define CYGNUM_HAL_STACK_INTERRUPT_SIZE \
     ((4 * 20) + 2 * CYGNUM_HAL_STACK_FRAME_SIZE)

#define CYGNUM_HAL_STACK_SIZE_MINIMUM \
         (CYGNUM_HAL_MAX_INTERRUPT_NESTING * 
CYGNUM_HAL_STACK_INTERRUPT_SIZE + \
          2 * CYGNUM_HAL_STACK_FRAME_SIZE)

If you could guarantee that interrupts will never nest in practice in an 
application, you could reduce this, but eCos in general can't make such an 
assumption. That's where that space is going anyway.

One bit of known wastage in the ARM HAL is the startup stack - 512 bytes. 
It probably shouldn't be used and instead an interrupt stack should always 
be defined and used for startup, irrespective of 
CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK which would instead 
determine the size of the interrupt stack in the ARM HAL rather than its 
presence or absence.

One regression we've had as well is that virtual vectors, and therefore 
hal_virtual_vector_table (272 bytes), are meant to be optional but many 
platform ports make them compulsory. On the plus side, it isn't difficult 
to make them optional.

eCos is designed to be small, but sometimes there are little things like 
this that linger for a while because no-one seems to be bothered about the 
last few bytes. I'd love to spend time clearing up stuff like this, but 
there's always something more important...

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
 >>>>> Visit us in booth 2527 at the Embedded Systems Conference 2004 <<<<<
March 30 - April 1, San Francisco http://www.esconline.com/electronicaUSA/
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss