rtems hello world, doesn't hit POSIX_init

Tue Oct 7 13:39:54 UTC 2014

On Mon, Oct 6, 2014 at 9:47 PM, alrik <alrik at utopiacompression.com> wrote:
> On 10/04/2014 08:18 AM, Joel Sherrill wrote:
>>
>>
>> On October 4, 2014 10:02:49 AM CDT, Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>> 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.
>>
>> There is a default configuration with an Init. I don't recall what it does
>> exactly but it probably doesn't include resources for C++. Maybe not even
>> POSIX objects. And it provides its own Init()
>>
>> We need to see the entire main.cpp
>>
>>> -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
>>
>>
>
> Hello,
>
> I've poked around some more (and switched away from using C++ for now, just
> C), and it looks like prior to hitting my POSIX_Init I was getting a fatal
> error whose code corresponds to "INTERNAL_ERROR_TOO_LITTLE_WORKSPACE". This
> happened when I would compile and link the separate codebase (but didn't
> include any of the files or call them in any way). If I removed some
> arbitrary number of source files from the separate codebase, then my 'hello
> world' would run as expected and I would see my printf's.
> Specifically, it seems that once my .text section would hit roughly the 100k
> byte mark, I would get the "INTERNAL_ERROR_TOO_LITTLE_WORKSPACE" error, but
> under that amount and everything would run as expected. The specific source
> files that I add or remove from the compilation doesn't seem to matter, just
> the overall .text section's size of my executable.
>
> I have since 'fixed' the error by adding
>
> #define CONFIGURE_UNIFIED_WORK_AREAS
> #define CONFIGURE_UNLIMITED_OBJECTS
>
> to my rtems configuration. I will likely have to figure out the right sizes
> at some point, but (luckily) that point is not now.
>
Good. It seems the problem is that you were encountering memory
pressure. Now the Workspace shares the same memory as the C Program
Heap, so there is less pressure in the workspace.

> On a side note, is there anywhere that these error messages have a more
> verbose description? I see the enum declaration of the errors in my rtems'
> header files, but is there some documentation about what their causes and/or
> meanings are somewhere? I've looked around the net, but I haven't found
> anything yet.
>
Not that I know of.

-Gedare

> Thanks for all the replies everyone, it helped expedite my search quite a
> bit
> Alrik
>