This is the mail archive of the
mailing list for the eCos project.
Re: finding out what's taking space in .bss
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: heinricg at esiee dot fr
- Cc: Andrew Lunn <andrew at lunn dot ch>, Gary Thomas <gary at mlbassoc dot com>,ecos-discuss at sources dot redhat dot com
- Date: Fri, 20 Feb 2004 04:26:33 +0000
- Subject: Re: [ECOS] finding out what's taking space in .bss
- References: <20040209161703.C94EC3658E4@mail.esiee.fr>
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
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
#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_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...
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