Crash in _User_extensions_Thread_create

Joel Sherrill joel.sherrill at
Wed Feb 20 20:55:53 UTC 2013

On 2/20/2013 2:39 PM, Matthew J Fletcher wrote:
> Hi,
> Ok so looking at the rtl22xx BSP as an example i can see the linker
> creates a .data section like so,
>    .data :
>    {
>      *(.data)
>      *(.data.*)
>      *(.gnu.linkonce.d*)
>      *(.jcr)
>      _edata = .;
>    } > sdram
> but in start.s there is no reference to the data section or the _edata
> symbol, so i've got no idea how that could setup the data section with
> the initialised variables in it.
> Thinking for a minute, would the linker script not need a symbol for
> both the beginning and the end of the data section so start.s knows the
> range to copy ? and then a loop in start.s to copy the data.
> I wonder if these BSP's are only suitable for execute from flash systems
> where you dont need to do the store -> ram copy of initialised data.
> Thats ultimately how i will run but i am running from RAM at the moment
> to ease (i thought !) being up and debugging.
I don't know this BSP that well. If the .data section has the proper 
values in it
when you get to boot_card(), then it is OK.

In some systems, the RAM would be loaded from Flash by start.S or something
similarly early.

In all cases, if you get to rtems_initialize_executive_early() (or even the
bsp_get_work_area() methods) and .data isn't right, you are in trouble.

Sebastian Huber should comment.

> On 20/02/13 17:25, Joel wrote:
>> On 2/20/2013 10:37 AM, Matthew J Fletcher wrote:
>>> Hi
>>> I dont define CONFIGURE_INITAL_EXTENSIONS so i was surprised to even
>>> be in this code. A #error in confdefs.h shows that its the
>>> RTEMS_NEWLIB define thats causing that path to be taken.
>>> The faulting line is the function pointer call into
>>> Callouts.thread_create as Callouts in uninitialised.
>>> I guess i am missing some #define that will setup this for me, i've
>>> looked in the samples folder and they just seem to #define the drivers
>>> they need, then #define the number of resources, then #define
>>> confdefs.h so i am a bit confused about the problem i am seeing.
>> There is very likely nothing wrong with your configuration via confdefs.h.
>> Assuming you are completely up to date... there is almost certainly
>> something
>> wrong with your layout or handling of initialized data.
>> Check Configuration_Initial_Extensions. It is initialized data and if it
>> doesn't have
>> pointers to the newlib extensions at download or by the time you get to
>> boot_card(),
>> then something is broken.  If it is correct and is overwritten by the
>> time you get to
>> using it, then something is overwriting it.
>> Memory layout and program initialization issues are a big part of
>> mysterious
>> failures at this point in a BSP.
>>> -- 
>>> regards
>>> ---
>>> Matthew J Fletcher

Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

More information about the users mailing list