rtems hello world, doesn't hit POSIX_init

Gedare Bloom gedare at rtems.org
Sat Oct 4 15:02:49 UTC 2014

On Fri, Oct 3, 2014 at 11:43 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> On October 3, 2014 9:18:45 PM CDT, Gedare Bloom <gedare at rtems.org> wrote:
>>On Fri, Oct 3, 2014 at 10:03 PM, alrik <alrik at utopiacompression.com>
>>> Hey all,
>>> I'm new to using rtems (and rtos'es in general), so apologies if my
>>> covers well-tread ground.
>>> I have a minimal, hello world type of main.cpp -- I use POSIX_Init as
>>> entry point, do a printf, then exit. I also am compiling a separate,
>>> code base and linking it into the executable, but I am not including
>>> files from it or calling any of the functions from there in my main
>>> When I run my application, it doesn't seem to ever hit my POSIX_Init
>>> point -- I don't see my printf call, and if I run it in a debugger
>>and look
>>> at the backtrace after it has completed, I get the following --
>>It's possible the printf simply never showed up before the board
>>resets. What target (BSP) are you using?
>>If you can set breakpoints with the debugger, you may want to place
>>one in POSIX_Init.
>>> moviDebug: INFO: IP = 70181110, , crt0.S, 338.
>>> moviDebug: INFO: IP = 7018B66C, _User_extensions_Iterate at 0x3C,
>>> userextiterate.c, 155.
>>> moviDebug: INFO: IP = 70188DF8, _Terminate at 0x20, userextimpl.h, 245.
>>> moviDebug: INFO: IP = 701985C0, rtems_gxx_mutex_init at 0x38,
>>> 178.
>>> moviDebug: INFO: IP = 70192FB4,
>>> _GLOBAL__sub_I___cxa_allocate_exception at 0x18, concurrence.h, 135.
>>> moviDebug: INFO: IP = 70199504, , pthreadself.c, 32.
>>> moviDebug: INFO: IP = 7019A7FC, , pthreadself.c, 32.
>>> moviDebug: INFO: IP = 70190DD0, _Thread_Handler at 0xF8,
>>threadhandler.c, 181.
>>> moviDebug: INFO: IP = 70190CD8, _Thread_Handler at 0x0, threadhandler.c,
>>> moviDebug: INFO: IP = CDCDCDCD, , pthreadself.c, 32.
>>> moviDebug: INFO: IP = ADADADAD, , pthreadself.c, 32.
>>> moviDebug: INFO: IP = 0, , confdefs.h, 68.
>>> I'm at a bit of a loss as to why this could be the case; I can run
>>this same
>>> rtems/posix 'hello world' correctly when I'm not linking to the
>>> large code base, but since I'm not including or calling any of that
>>> files or functions, how can it be having this effect (i.e. my
>>> inability to get to the entry function)?
>>That "cxa_allocate_exception" is certainly suspicious to me. I don't
>>use C++ enough to know, but that backtrace kind of looks like a mutex
>>failed to initialize due to out-of-memory. Perhaps the memory is
>>exhausted? How much memory is available? How big is the executable?
>>You can use rtems4.11-arch-size to get the size of the linked binary.
>>Compare that to the memory available in the platform. You can run
>>spsize to get an idea of the runtime overhead to get base RTEMS up.
> More likely not out of memory but not accounting for the resources used. Probably easier to configure with unlimited objects to make it work.
Maybe, although why would the version without linking against the
other code base work?

It would be helpful to see the main.cpp and RTEMS_CONFIGURE_X macros
that are used, if possible.


>>> Thanks,
>>> Alrik
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>users mailing list
>>users at rtems.org

More information about the users mailing list