Re: Initialize data section in arm/crt0.S

[Richard Earnshaw <rearnsha at arm dot com>]

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
configuring newlib.

R.

> Regards
> 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
>> users.
>>
>> 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).
>>
>> Regards,
>>
>> 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,
>>> Frank
>>>
> 
>