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

[<heinricg at esiee dot fr>]

> > > > I'm looking for advice on how to reduce RAM requirements,
which
> > > > packages usually take space, how to find out where objects
that
> > take
> > > > space are located.
> > > 
> > > Starting with the minimal template is probably a good idea. Than
add
> > > any packages you do need. 
> > > 
> > >     Andrew
> > > 
> > 
> > as you said, the symbol must have been automatically added by the
> > build system. After getting rid of the memalloc package, it
> > disappeared.
> > After removing many packages, the code size was divided by 4, but
the
> > .bss section size was just down to about 12k. However, when I use
the
> > nm command, the biggest object is 0x84 bytes long and I don't get
that
> > many objects. I guess the sum of the object sizes within .bss is
below
> > 1KB.
> > 
> > Is there some kind of buffer or anything that is located in .bss
but
> > not showed by nm?
> > 
> > Would you suggest another way of investigating the contents of
.bss?
> 
> What you see in the map is what you'll use (if you're not using a
heap).
> 
> Maybe now that you've whittled it down, you could send the map (sort
> it using -n) and we can comment.

I removed some more packages and size now reports 3816 bytes in 
the .bss section. Ideally I would like it to be even smaller.

I should've said earlier that I only took "B"-type symbols into
account. nm actually reports more symbols. I think this was the source
of my confusion, since I thought other types of symbols were mere
symbols and didn't "eat" space.

Below is an excerpt of why I get when I do "arm-elf-nm -n -C -S -l
a.out" after linking the simplest application ( int main(void) {
return 0;} ). In my memory map, the RAM starts at 0xd0000 and ends at
0xd19ff). I have only quoted the symbols located in that range of
addresses. 

000d0000 ? hal_vsr_table
000d0020 ? hal_dram_size
000d0024 ? hal_dram_type
000d0030 ? hal_virtual_vector_table
000d0140 A __ram_data_start
000d0140 d init_flag
000d0144 D hal_interrupt_handlers
000d0198 D hal_interrupt_data
000d01ec D hal_interrupt_objects
000d0240 00000004 D cyg_scheduler_sched_lock
000d0244 00000004 d Cyg_Scheduler::start_cpu()::__cygvar_discard_me__
000d0248 00000004 D Cyg_Clock::real_time_clock
000d024c 00000060 d construct_converter(Cyg_Clock::converter*,
unsigned long long, unsigned long long, unsigned long long, unsigned
long long)::primes
000d02ac 00000008 D rtc_resolution
000d02b4 00000002 d next_unique_id
000d02b8 A __CTOR_LIST__
000d02cc A __CTOR_END__
000d02cc A __DTOR_LIST__
000d02dc A __DTOR_END__
000d02dc A __bss_start
000d02dc A __ram_data_end
000d02dc A _edata
000d02e0 b __exception_stack_base
000d0360 b __exception_stack
000d03e0 b __startup_stack_base
000d03e0 b __undef_exception_stack
000d0be0 00000004 B Cyg_Scheduler_Base::current_thread
000d0be0 b __startup_stack
000d0be4 00000004 B Cyg_Scheduler_Base::need_reschedule
000d0be8 00000084 B Cyg_Scheduler::scheduler
000d0c6c 00000004 B Cyg_Scheduler_Base::thread_switches
000d0c70 b _period
000d0c74 00000034 B Cyg_RealTimeClock::rtc
000d0ca8 00000008 B Cyg_Thread::exception_control
000d0cb0 00000004 B Cyg_Interrupt::disable_counter
000d0cb4 00000004 B Cyg_Interrupt::interrupt_disable_spinlock
000d0cb8 00000004 B Cyg_Interrupt::interrupt_disable_state
000d0cbc 00000004 B Cyg_Interrupt::dsr_list
000d0cc0 00000004 B Cyg_Scheduler_Implementation::timeslice_count
000d0cc4 b idle_thread_stack
000d1124 00000004 B idle_thread_loops
000d1128 0000006c B idle_thread
000d11a0 00000004 B _cyg_hal_compiler_dummy
000d11c0 00000004 B __mem_fault_handler
000d11c4 A __bss_end
000d11c4 A _end
000d11c8 A __heap1

what are those absolute (A) symbols for which no size is given? 

Apparently, I have a 2k exception_stack between D03E0 and D0BE0. I
also have over 1k in the idle_thread_stack. I may need to investigate
this.

Many thanks for your help,
Cheers,
Greg.

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