Initialize data section in arm/crt0.S
Tue Jul 15 13:48:00 GMT 2014
I've been through a similar process, in the SPARC(LEON) world, rather
than ARM, and after looking at just about every crt0.s and linker
script in libgloss for inspiration, I eventually settled on having two
different linker scripts, one for RAM builds, and one for PROM.
My crt0 checks the VMA and LMA of the .data segment to decide whether
or not a copy is required. These will be the same when building for
RAM, but different in a PROM build. I also use link-time flags to
control other options in the scripts, providing more flexibility for
There isn't (as far as I know) a "reference version" of crt0, or of
linker scripts, but reading through the examples in the various
platform directories should give you ideas of what can be done, and
what's a good idea to include (or omit).
On 15 July 2014 07:49, Pilhofer, Frank <Frank.Pilhofer@zuehlke.com> wrote:
> On 07/14/14, Richard Earnshaw wrote:
>> I don't think this is right. The standard crt0 is supposed to work with conventional loadable image files (like an ELF executable). Such images have initialized data in the correct location; on the other hand, the zero-initialized data does not exist in the image and the file format just specifies how large the uninitialized data segment is. A real loader (such as in Linux) would do the zero-initialization for the code, but there's no loader in a bare-metal system, so it has to do it itself.
> Richard, I think this information is the missing link that I was looking for. So it appears that I will not be able to use _start as the entry point. The people at gcc-arm-embedded also suggested that I have to provide my own entry point that initializes BSS and data, and then calls _mainCRTStartup, which is an alias for _start in crt0.S. That should do the trick.#
> It just seemed odd that I have to do the data initialization myself, but your explanation makes sense. Yes, the application is in flash, there is no loader, but the data must be initialized somwhere after a reset.
>> Furthermore __data_load__ is not a standard symbol exported by linker scripts, so this would just break most uses of this file.
> I am also wondering about these names. I have found many linker scripts, but they are not consistent, and they seem to contain a lot of crud (dozens of section names that seem very specific). Is there a list of standard symbol names and section names? Is there a reference linker script somewhere?
> Thank you,
More information about the Newlib