Initialize data section in arm/crt0.S
Tue Jul 15 15:20:00 GMT 2014
On 15/07/14 16:17, David Fernandez wrote:
> 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.
This is where libgloss comes in. That's supposed to be the glue layer
that you need to replace for your specific environment. For ARM you'll
probably need something like --disable-newlib-supplied-syscalls when
> David F.
> 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).
>> David P.
>> 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