Comments in mfile for GCC4.2.2 up-to-date?

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

Hello,

I had an older project, which was originally build with WinAvr20040720 (GCC 3.4.1), where I put the globals (and the heap) into the external memory.
In the Makefile I used:

EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

It does not seem to work anymore. I can see in the mapfile that the data+bss starts at 800100 (=internal RAM) and not at 801100 (=external SRAM).

I generated a new Makefile with mfile. The annotations in the file says that the line above should be all right.
But if I select 'vars+heap to external RAM' in the menue of mfile I got:
EXTMEMOPTS = -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x80ffff

So, I assume that this

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# used for variables (.data/.bss) and heap (malloc()).
#EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# only used for heap (malloc()).
#EXTMEMOPTS = -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x80ffff

must be this:

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# used for variables (.data/.bss) and heap (malloc()).
#EXTMEMOPTS = -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x80ffff

# 64 KB of external RAM, starting after internal RAM (ATmega128!),
# only used for heap (malloc()).
EXTMEMOPTS = -Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff

Are my assumptions correct?

Michael

In the beginning was the Word, and the Word was with God, and the Word was God.

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

You are correct. Please file a WinAVR bug report on sourceforge.net.

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

OK, Jörg, it is bug ID=1869080.

If the option -Tdata is not possible at all with the linker of GCC4.x.y, the documentation also should be updated.
(chapter 9.2.3; page 269 in latest public release)

Michael

In the beginning was the Word, and the Word was with God, and the Word was God.

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

OK, I assigned the bug to myself.

Sorry, I don't have a clue which documentation you are talking about.
-Tdata /is/ possible, but for some MCU types it collides with the
compiler's own internal use of -Tdata (to move the data segment from
0x60 to 0x100 or 0x200).

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

I've seen something like that before... I think it might be one of the GCC bugs. Something about -Tdata and the mega8 or something like that.

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

No, it's due to our way we massage the linker arguments inside GCC.
If the user also uses -Tdata, the linker command-line possibly ends
up with two conflicting -Tdata options. The order towards this
conflict has been resolved did change between binutils 2.16 and 2.17,
so it's now necessary to use --section-start=.data which will override
the -Tdata passed from GCC itself.

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

It was noticed in an application with ATmega128.
The main application code was about 60kByte. Additionally there are some bootloader sections.

I thought the -Tdata option was obsolete, because it did not work, but with the 'section-start' it was like on my old WinAVR20040720.

But good news, Eric (I have to post it also in another thread):
The code was smaller with WinAVR20071221 (GCC 4.2.2) than with WinAVR20070525 (GCC 4.1.2) and also WinAVR20040720 (GCC 3.4.1).

---
Edit:
see https://www.avrfreaks.net/index.p...

In the beginning was the Word, and the Word was with God, and the Word was God.