This is the mail archive of the
mailing list for the newlib project.
Re: Re: Initialize data section in arm/crt0.S
- From: David Fernandez <david dot fernandez dot work at googlemail dot com>
- To: David Paterson <dnpaterson at gmail dot com>, "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 16:17:36 +0100
- Subject: Re: Re: Initialize data section in arm/crt0.S
- Authentication-results: sourceware.org; auth=none
- References: <CAM1kHc0n9-BM7YwpEzHi=2uHAaNaAAyUvVM3_EZSg5zvTL7X2w at mail dot gmail dot com>
Not sure if newlib supports that but, aside from replacing crt0.S with
your own special version, the linker scripts usually allow to have the
code that you want in a .init<N> code section that gets merged into the
final initialization code... That way your system can provide code for
that initialization when producing the final binary.
Some newlib maintainer might comment about that.
On 15/07/14 14:48, David Paterson wrote:
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?