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>
>>wrote:
>>> Hey all,
>>>
>>> I'm new to using rtems (and rtos'es in general), so apologies if my
>>question
>>> covers well-tread ground.
>>>
>>Welcome!
>>
>>> I have a minimal, hello world type of main.cpp -- I use POSIX_Init as
>>my
>>> entry point, do a printf, then exit. I also am compiling a separate,
>>large
>>> code base and linking it into the executable, but I am not including
>>any
>>> files from it or calling any of the functions from there in my main
>>file.
>>>
>>> When I run my application, it doesn't seem to ever hit my POSIX_Init
>>entry
>>> 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,
>>gxx_wrappers.c,
>>> 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,
>>89.
>>> 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
>>separate,
>>> large code base, but since I'm not including or calling any of that
>>code's
>>> files or functions, how can it be having this effect (i.e. my
>>program's
>>> 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.
-Gedare
>>-Gedare
>>
>>> Thanks,
>>> Alrik
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>_______________________________________________
>>users mailing list
>>users at rtems.org
>>http://lists.rtems.org/mailman/listinfo/users
>
More information about the users
mailing list