A little help understanding the linker .map file

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guyzz

Im decipering the linker map file , to get an idea about how long my program is.

This is where program starts (well i know that) .text = Prog mem

At first it didnt seem to match the "Memory window (program)" in AvrStudio , as it seemed to stop at around 0x091c , thats where the "plain FFFF's" began.

But i think its Words not Bytes in the AvrStudio , correct ??
Then it makes sense because 0x1234 = 0x91a words.

Im my mapfile there is this : Is the linker being nice here and write the .etext on the .text line so i don't have to search through file in order to see length ???? , or is it just a coincidence ?? (I think/hope the first)

.text 0x00000000 0x1234
..
..
0x00001234 _etext = .

Thanx

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forget about the cryptic map file. I have yet to find any purpose
where deciphering it would really be needed for. ;-)

For your purpose, simply watch the output of the avr-size [-A]
command. If you've got the WinAVR default Makefile template (or an
Mfile-generated Makefile, which is based on that template), this will
be sent out to standard output after linking the application by
default.

Please use the forum search function for more explanations what is
what in that output, it has been posted numerous times.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the ansver

I tried the avr-size on the .o file , looks neat.

But if i want info about file loaded into the avr (elf/coff/hex) file.

I found out that avr-readelf -l .elf

produces a nice display

Elf file type is EXEC (Executable file)
Entry point 0x0
There are 3 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000094 0x00000000 0x00000000 0x01234 0x01234 R E 0x1
LOAD 0x0012c8 0x00800060 0x00001234 0x00000 0x00000 RW 0x1
LOAD 0x0012c8 0x00800060 0x00800060 0x00000 0x000b2 RW 0x1

Section to Segment mapping:
Segment Sections...
00 .text
01
02 .bss

/Bingo

Ps: Sorry i did'nt use search

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:
I tried the avr-size on the .o file , looks neat.

But if i want info about file loaded into the avr (elf/coff/hex) file.

If you are using the WinAVR sample makefile then around line 265 change this (ignore the line wrapping due to the web forum):

sizebefore:
	@if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); echo; fi

sizeafter:
	@if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); echo; fi

to this:

sizebefore:
	@if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_BEFORE); $(HEXSIZE); echo; fi

sizeafter:
	@if [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_AFTER); $(HEXSIZE); echo; fi

Note the change of $(ELFSIZE) to $(HEXSIZE) in both lines.

This will give you the size of the Intel Hex file, which is only good to tell you how much program memory you will use but it won't tell you the size of the various sections inside your code.

Again, search in this forum for more information about the various kinds of output avr-size can give you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I tried the avr-size on the .o file , looks neat.

It works on any (ELF) object file, regardless of whether it's a
relocatable object (.o), or a loadable file (.elf). Actually, the
display of .bss and .noinit might be wrong on the .o files, they only
sum up correctly once the linker did its job, due to the way the
compiler allocates the space for objects in these sections (.comm --
reminiscent of FORTRAN COMMON blocks -- objects by the same name from
different modules are overlaid by the linker).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.