This is the mail archive of the
mailing list for the newlib project.
Re: Initialize data section in arm/crt0.S
- From: David Paterson <dnpaterson at gmail dot com>
- To: "Pilhofer, Frank" <Frank dot Pilhofer at zuehlke dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 15 Jul 2014 14:48:35 +0100
- Subject: Re: Initialize data section in arm/crt0.S
- Authentication-results: sourceware.org; auth=none
- References: <7b0d9c60e7aa48b79a38bae524fe315d at zrhex030 dot ads dot zuehlke dot com> <53C3F9FA dot 9080104 at arm dot com> <23ee0f0341a14828aabfbc1c4d887bc1 at zrhex030 dot ads dot zuehlke dot com>
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,