> Your solution seems likely to cause so many other problems :)
> .data should be writable, so you should not put its VMA in ROM

In our setup it wasnt. Allowing data to be writable caused far more
problems. I'm not going through all the code marking stuff as const when
there is no need...

> How do you clear the bss section when you don't PROVIDE symbols for it.

If you clear all work ram then the BSS is cleared... as most people do. ??

> Heck, what happens to data in .ao files?

Data in .ao files is added to the end of rom. It works it out from the
memory definitions.

> You should declare iwram to be smaller than it is to leave room for stack.

True.

> C++ couldn't possibly work with this script.

True. We dont use it, hence I dont support it.

> Doing things in linker scripts with specific file names or extensions is
> too hacky for me. Although extensions seem less hacky than whole
> filenames (this is just my opinion however).

It's the least hacky way I have found. If there is a more magical way, let
others know.

Specifying different segments to different functions was a pain in the arse
and caused more problems.

It may be hacky, but it works.

> I come to the conclusion that your simple linker script is too simple ^_^

It works for me, if it doesnt work for you, fix it.

It was put out as an example of how to get code to run -- which many people
have had problems with.

If you can do better, please feel free to share it with everyone.

> I'd tell you to go back to the drawing board, but Jeff should be releasing
> a lnkscript soon which does everything right (well, at least one version

Um, works for me 100%. It was never supposed to be a be all and end all of
linker scripts, I was being thoughtfull and providing other people a
building block to work on.

If you are so great, please feel free to write the mother of all linker
scripts and find some ingenious way of specifying segments for ARM code and
THUMB code without GCC throwing a wobbly.

Best of luck.

--Jim