This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Initialize data section in arm/crt0.S


David,

my motivation was to not replace crt0.S, and to use as much of the existing infrastructure and glue code as possible.

I have now solved my problem using a hand-written entry point (used as reset vector) that, as Richard suggested, initializes data and BSS. After that, it jumps to _mainCRTStartup() as supplied by libgloss, which does the rest (calling hardware_init_hook(), software_init_hook(), __libc_init_array(), and eventually main()). That seems reasonable.

One thing I haven't figured out yet is the common naming convention for the linker-provided symbols for the start and end addresses of the data section, if there is one.

Frank


-----Original Message-----
From: David Fernandez [mailto:david.fernandez.work@googlemail.com] 
Sent: Dienstag, 15. Juli 2014 17:18
To: David Paterson; Pilhofer, Frank
Cc: Richard Earnshaw; newlib@sourceware.org
Subject: Re: Re: Initialize data section in arm/crt0.S

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.

Regards
David F.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]