empty space between .data section symbols

Log in or register to post comments
Go To Last Post
3 posts / 0 new
Author
Message
riccardomanfrin
riccardomanfrin's picture
Level: Hangaround
Joined: Tue. Apr 27, 2010
Posts: 103 View posts
#1
Posted by riccardomanfrin: Thu. Feb 14, 2013 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,
I'm watching the elf image .data section and have sorted all the symbols offsets with the following command:

/usr/local/avr/bin/avr-objdump -t image.elf --demangle |grep "\.data" |awk '{print "0x" $0}'  |sort -n

If I sum up all the reported symbol's sizes I get about 5.4KB. If I watch the sections size with this command:

/usr/local/avr/bin/avr-objdump -h image.elf

I get this

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0002c288  00000000  00000000  00000094  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00002ee6  00802000  0002c288  0002c31c  2**0
                  CONTENTS, ALLOC, LOAD, DATA

and the .data section size turns out to be 12KB.
Now, once I watched the symbols offsets and sizes more carefully I noticed that there are several misalignments ("holes") between the offsets differences and the symbols sizes, as is shown in the following example:

0x008049cb  w    O .data	0000000e vtable for os_msg_queue_if_t
0x00804a18  w    O .data

As you see 0x4a18 - 0x49cb = 0x4D which is >> 0xE. Am I missing something / doing something wrong? I understand there can be static data that is not shown in the symbols, but to have 12 - 5.4 =6.6KB of static data is odd to me.
Is this related to the "impure data" ? because I don't see the "impure_data" symbol in the list.

Funny thing is the same code compiles on a cortex M3 and only eats up 980B of ram in the data section (of which 400B are for impure_data).
So I'm losing about 4K for vtables and other 6.6K for something which I don't know.

I'm sorry not to be specific enough but can you suggest me something to investigate or something to report to you in order to focus the problem?

Thanks in advance.
R

Tags:

AVR Microcontrollers, AVR and XMEGA
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 105140 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Feb 14, 2013 - 05:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does the .map show? Also note that "static" will be in .data/.bss but won't be named in .map or nm output.

Top
riccardomanfrin
riccardomanfrin's picture
Level: Hangaround
Joined: Tue. Apr 27, 2010
Posts: 103 View posts
Posted by riccardomanfrin: Mon. Feb 18, 2013 - 10:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
What does the .map show? Also note that "static" will be in .data/.bss but won't be named in .map or nm output.

I'm going to detail a bit further with an example. I have a class "foo_t" defined in "foo_t.cpp".

Inspecting the image map file .data symbols, I found the following references to foo_t:

...

 .data          0x0000000000804b7c      0x32c foo_t.o
 				...
                0x0000000000804d34                _ZTV13foo_t
 .data          0x0000000000804ea8       0x34 tester.o

If I run objdump -t on the whole elf image and inspect the data section with this command

avr-objdump -t image.elf --demangle |grep "\.text" |awk '{print "0x" $0}'  |sort -n

I find this output:

0x00804d34  w    O .data	00000024 vtable for foo_t
0x00804e98 l     O .data	00000010 bc_addr
0x00804edc g     O .data	00000002 __malloc_margin

Finally, if I directly inspect foo_t.o with 

avr-objdump -t --demangle foo.o |awk '{print "0x" $0}'|sort -n |less

I get this output:

0x000001b8  w    O .data        00000024 vtable for foo_t
0x000001ce  w    F .text        0000001a ...
0x000001dc  w    O .data        0000000a vtable for yet_another_foo_t

Now going back to the symbols relocated in the whole image.elf file, the symbol "yet_another_foo_t" is not placed at the same offset from "foo_t", but much sooner (address 0x00802ff5), and nothing is put in its place.

My ignorant feeling is that the linker is somehow relocating symbols without eventually removing the holes that are so created in .data section.

If you think it can be useful I can provide you with my linking options:

avr-g++ -mmcu=atxmega256a3 -Xlinker --relax -Xlinker -Map=image.map -T system/toolchain/avrxmega/linkerscript.ld -Os

Do you have any hint on what is happening and why?

Thanks in advance,
R

Top