Re: [coldfire-gnu-discuss] Linker files and startup code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxxxxxxxx    ::     http://www.planetfall.pwp.blueyonder.co.uk