GNU Arm Embedded Toolchain

__sinit -> __sfp --> __sinit infinite recursion

Asked by dave m.

Using gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 on a Cortex-M0, I'm having trouble getting stdio working. When I call any function that wants to use stdin/stdout/stderr, I get into an infinite recursion between __sinit and __ssfp. (The formatting code works -- I can use sprintf() and friends -- but printf() crashes.) I assume there's an initialization step that's not happening in my startup code, but I haven't been able to trace it out. Can anybody hit me with a clue stick?

Thanks!

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Joey Ye
Solved:
Last query:
Last reply:
Revision history for this message
Best Joey Ye (jinyun-ye) said : 		#1

Yes there is an initialization stage. Please call _start for initialization, which will later call to main after init done.

Revision history for this message
dave m. (z-launchpad-mersenne-com) said : 		#2

Ha ha! That would explain it: not only did I not call _start; my own crt0 entry function is named _start! so the proper initialization isn't even pulled out of the library!

Thanks very much!

Revision history for this message
dave m. (z-launchpad-mersenne-com) said : 		#3

Thanks Joey Ye, that solved my question.

Revision history for this message
dave m. (z-launchpad-mersenne-com) said : 		#4

After looking at the many crt0.S files in the source tree, is there an overview doc of what library-specific things need to be set up? The provided versions are complicated by the need to support many different processors in each file (using a bunch of preprocessor macros & etc.). I totally understand why those are so complicated, but I've been bitten enough times by not-exactly-right hardware init in crt0 that I always do it myself these days.