How to analyze .data & .bss section

Projects Programming
1

I'm running a bit low on memory and would therefore like to analyze the data & bss section a bit. Below is the output from avr-size...

avr-size --format=berkeley  cockpit.elf
   text	   data	    bss	    dec	    hex	filename
  27024	    262	    815	  28101	   6dc5	cockpit.elf

My "Main-Object" (Cockpit) is a singelton whichs "owns" every other (child) objects. All of the childs are allocated on the stack - even though, some of the child objects do use the heap internaly (i.e. linked list). Sizeof(Cockpit) outputs 260bytes. After startup (initalizing the singleton) i have 530bytes free memory. All of my string literals are surrounded by the F()-Macro - so they shouldn't eat up the memory.

I'm trying to analyze the objects with the following command

avr-objdump -C -d -S -t -j .bss -j .data cockpit.elf

In the output i do see some (but not all) of my objects/class/variables/symbols...and...i don't know how to determine the size of the symbols. Is there another command switch to show the size in dec ? Or is there another tool which can do the job ?

What I'm basicly trying to do is, to get a rough understanding to which instance/object the 1077bytes (262+815) from the data/bss section belong to - and where the other 441bytes (2048-1077data-530free) remaining bytes go to

2 
008001fd <vtable for HardwareSerial>:
  8001fd:	00 00 00 00 9b 2d 2e 2f 3f 2d 6e 2d 52 2d 90 2d

this to that mean, that the size of the vtable for HardwareSerial is 16bytes ?

00800152 <vtable for PinChangeInterruptCounter<unsigned short>>:
  800152:	00 00 00 00 50 1f fd 1f cb 1b 8f 1b 2e 00 43 6f     ....P.........Co
  800162:	63 6b 70 69 74 00 4c 49 4e 46 4f 3a 20 73 6f 6d     ckpit.LINFO: som
  800172:	65 20 6c 6f 67 20 65 6e 74 72 69 65 73 0a 4c 45     e log entries.LE
  800182:	52 52 4f 52 3a 20 6d 6f 72 65 20 6c 6f 67 0a 4c     RROR: more log.L
  800192:	54 52 41 43 45 3a 20 74 72 61 63 65 20 65 6e 74     TRACE: trace ent
  8001a2:	72 79 0a 00                                         ry..

and here it would be 84bytes ? :astonished: