rtems hello world, doesn't hit POSIX_init

[alrik]

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.

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.

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