[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Static memory footprint analysis
- Date: Tue, 10 Mar 2009 06:20:32 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: Static memory footprint analysis
Ingolf Steinbach wrote:
> Thanks, Chris.
> 2009/3/10 Chris Johns <chrisj at rtems.org>:
>> The libc, networking or other services could be calling malloc. For example
>> printf will cause stdout to allocate a buffer.
> No networking/printf. However, I see that malloc() is pulled in
> nevertheless, so probably, there's some RTEMS code requiring it.
>> Newer versions of RTEMS have heap reporting functions that help here.
> What should I look at in order to evaluate the actual (run-time)
> memory footprint for 4.6.5?
My first question would be is any of the malloc() family
part of your executable. If it is not, then it isn't a factor.
I know that it is not unusual for the space community to
avoid use of the parts of RTEMS that use malloc.
If malloc is in the executable, the most certain thing
is to objdump -da and look for the calls to malloc. That
will show where it is called. Then you have the list
of areas that malloc that impact your application.
RTEMS proper should not be calling malloc(). It will
be the filesystem, libcsupport, libc, TCP/IP and drivers
that do it.
With malloc contained, you only have to worry about
There is no point in analyzing everything since your
application defines a known subset.
> Kind regards
> rtems-users mailing list
> rtems-users at rtems.com