[coldfire-gnu-discuss] Linker files and startup code

[Nathan Sidwell]

David Brown wrote:

> but my own code.  This post is a few comments on what I have seen so 
> far, which may be of interest to the CodeSourcery guys (many thanks for 
> your work, by the way!) or other users.

thanks for taking the time to comment.

> First off, it's a tough job finding the source code for the startup 
> files.  I tracked down the appropriate crt0.S, though it would be *very* 
> useful to have had that in the binary build distributions as well as the 
> source distribution.  But I can't trace the sources for crtbegin.o or 
> crtend.o anywhere.  Since they are small, an objdump disassembly listing 
> is not bad, but I'd like to know where they came from...

we realized that too :) The next releases will include the crt source code in 
the binaries too (placed alongside their compiled versions).  crtbegin.o and 
crtend.o are a different matter and we hadn't thought about them.  They are part 
of the compiler and are in gcc/crtstuff.c -- it is compiled twice with #define 
telling it whether it'll be crtbegin or crtend.  That source file is not 
compilable outside of gcc, so I'm not sure how useful or misleading it might be 
to include it along with crt0.S etc.

> The linker scripts and the crt0.S seem to be based entirely on the idea 
> that the code is running from ram.  On many ColdFire's, that is the case 
> - you have a bootloader of some sort which copies the code from slow 
> flash into fast ram for execution.  But on the more integrated devices 
> like the 5213, you need to run the code from flash.  This means that the 
> loader scripts should support the separate memory areas, with code going 
> in flash, bss going in ram, and data going in flash but with logical 
> addresses in ram, and the crt0 startup should copy the initial values 
> into ram.

Correct.  We've been adding flash programming support, but it is not ready yet. 
  We've also added ram and rom variants of the linker scripts along with hosted 
and unhosted versions.

> A minor point about the crt0.S code is that it clears the bss section 
> byte by byte.  On the ColdFire, writing 32-bit words will clear the 
> section about four times as fast.

yeah, that's fixed too :)  the crt0.S code had a long history, but we've 
reengineered a coldfire specific version now.

It seems we've addressed all your issues in our internal development.  New 
public releases are planned for the end of this month containing these updates.

Of course, if you had a subscription (either Personal or Professional), you 
wouldn't have had to wait so long for some of the features you mentioned.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan at codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk