rtems with matlab autocode problems

Joel Sherrill joel.sherrill at OARcorp.com
Thu Jun 17 15:40:37 UTC 2010


On 06/17/2010 10:29 AM, Jiri Gaisler wrote:
> At -O3, some versions of gcc will use %f registers to pass
> integer parameters. This will cause a trap if RTEMS_FLOATING_POINT
> is not set ...
>    
Doesn't that also make it ABI incompatible with
any code compiled at -O2 or lower or -Os?

--joel
> Jiri.
>
> João Rasta wrote:
>    
>> I'm not sure what could have cause the pattern. I would say a memory
>> overwrite as already suggested but i'm still not aware of its source.
>>
>> Update:
>> No problems with -O2.
>> I also included the RTEMS_FLOATING_POINT as instructed by Jiri and
>> everything goes well.
>>
>>
>> Best,
>> JM
>>
>> On Thu, Jun 17, 2010 at 4:11 PM, Andrei Chichak<groups at chichak.ca
>> <mailto:groups at chichak.ca>>  wrote:
>>
>>      Just an observation:
>>
>>      The pattern that is being printed has the hex values AA 99 55 66.
>>      First, it's pretty odd that all of the nybbles are the same in each
>>      byte. Next, the first and third bytes are complements of each other
>>      as are the second and fourth.
>>
>>      This looks like a test pattern.
>>
>>      Andrei
>>
>>
>>      On 2010-June-16, at 11:48 AM, João Rasta wrote:
>>
>>      
>>>      Yes, here goes
>>>
>>>      // dummy printf test code
>>>      int upa(void)
>>>      {
>>>          int i = 0;
>>>
>>>          for (i=0; i<  20; i++)
>>>              printf("B\n");
>>>
>>>          exit(0);
>>>
>>>      }
>>>
>>>      And the result is:
>>>
>>>
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>          ¬ÖUf
>>>
>>>      Program exited normally. This same code works correctly if i put
>>>      the function in the main code instead of the library code. I still
>>>      have no idea of what can be causing this, any hints would be
>>>      apreciated. Mabe a compiler flag is messing up the library code?
>>>
>>>      The matlab autocode makefile generates some flags i don't
>>>      recognize such as the DXXX:
>>>
>>>      sparc-rtems-gcc -c -O3 -g3 -ffloat-store -fPIC   -DUSE_RTMODEL
>>>      -DMODEL=gnc -DRT -DNUMST=1 -DTID01EQ=0 -DNCSTATES=0 -DUNIX -DMT=0
>>>      -DHAVESTDI
>>>      O   -I. -I../../rtwlt/matlab/simulink/include
>>>      -I../../rtwlt/matlab/extern/include -I../../rtwlt/matlab/rtw/c/src
>>>      -I../../rtwlt/matlab/rtw/c/
>>>      src/ext_mode/common -I. -I.. -I../../rtwlt/matlab/rtw/c/libsrc
>>>      ../../rtwlt/matlab/rtw/c/src/rt_sim.c
>>>
>>>
>>>      These flags are not used in the "main" code, for instance
>>>
>>>      sparc-rtems-gcc  -DLOGGING=1 -DLOGNOTORIETY=10 -I"../src"
>>>      -I"../src/comms/packet_lib" -I"../src/shell" -I"../src/comms"
>>>      -I"../model/gnc_linu
>>>      x" -I../rtwlt/matlab/simulink/include
>>>      -I../rtwlt/matlab/extern/include -I../rtwlt/matlab/rtw/c/src
>>>      -I../rtwlt/matlab/rtw/c/src/ext_mode/comm
>>>      on -I../rtwlt/matlab/rtw/c/libsrc   -O2 -g -Wall -c
>>>      -fmessage-length=0 -DRT -MMD -MP -MF"src/common.d"
>>>      -MT"src/common.d" -o"src/common.o" ".
>>>      ./src/common.c"
>>>
>>>      Has anyone seen the DXX flags?
>>>
>>>      Best,
>>>      JM
>>>
>>>
>>>      On Wed, Jun 16, 2010 at 6:31 PM, Till Straumann
>>>      <strauman at slac.stanford.edu<mailto:strauman at slac.stanford.edu>>
>>>      wrote:
>>>
>>>          Can you post the offending code?
>>>
>>>          T.
>>>
>>>
>>>          On 06/16/2010 12:02 PM, João Rasta wrote:
>>>        
>>>>          Just an update:
>>>>
>>>>          If i do fflush(stdout) inside the test function, the
>>>>          application crashes. Also, no matter what i put in printf, it
>>>>          allways prints the same characters, but it detects the \n
>>>>          correctly.. I don't see if this can be related to the compiler..
>>>>
>>>>
>>>>          Best,
>>>>          JM
>>>>
>>>>          On Wed, Jun 16, 2010 at 4:56 PM, Joel Sherrill
>>>>          <joel.sherrill at oarcorp.com
>>>>          <mailto:joel.sherrill at oarcorp.com>>  wrote:
>>>>
>>>>              On 06/16/2010 10:52 AM, João Rasta wrote:
>>>>
>>>>                  Hi,
>>>>
>>>>                  No, autocode requires the real-time workbench only,
>>>>                  it is quite straightforward to generate the code.
>>>>
>>>>                  I didn't fully understood your question. Anyway, i
>>>>                  have tried to compile the application with gcc and
>>>>                  runs fine on linux so it should run on rtems with the
>>>>                  apropriate modifications. However, when i
>>>>                  printf("test\n") within the library finction, it
>>>>                  returns strange characters, which doesn't happen in
>>>>                  the function that calls the library function..
>>>>
>>>>              Is it including stdio.h?  I have seen some targets where
>>>>              if you don't the variable
>>>>              arguments stuff gets confused.
>>>>
>>>>              Is the generated code warning free?
>>>>
>>>>
>>>>                  I suspect of a compilation flag/option i may be
>>>>                  missing on the library. Do you have any idea?
>>>>
>>>>              As long as it is compiled the same as the rest of the
>>>>              app, it should be ok.
>>>>
>>>>                  Also, i don't need any rtems
>>>>                  primitives/configurations on the library functions
>>>>                  right? I'm assuimng It is enough to have the rtems
>>>>                  configuration on the "main" file.
>>>>
>>>>              Right.
>>>>
>>>>              Can you print from other tasks?
>>>>
>>>>              --joel
>>>>
>>>>
>>>>                  Best,
>>>>                  JM
>>>>
>>>>
>>>>
>>>>
>>>>                  On Wed, Jun 16, 2010 at 4:42 PM, Joel Sherrill
>>>>                  <joel.sherrill at oarcorp.com
>>>>                  <mailto:joel.sherrill at oarcorp.com>
>>>>                  <mailto:joel.sherrill at oarcorp.com
>>>>                  <mailto:joel.sherrill at oarcorp.com>>>  wrote:
>>>>
>>>>                     On 06/16/2010 10:38 AM, João Rasta wrote:
>>>>
>>>>                         Hi,
>>>>
>>>>                         I'm having trouble running an rtems
>>>>                  application that uses code
>>>>                         generated from matlab using autocode. It all
>>>>                  goes well until a
>>>>                         function of this library is called: printfs
>>>>                  return awkward
>>>>                         characters and then the application crashes.
>>>>
>>>>                     I have seen references to this before.  Is this
>>>>                  hard to do?  Are
>>>>                     there instructions?
>>>>                     Standard glue code, etc.
>>>>
>>>>                         1) Is there any obvious reason to why printfs
>>>>                  of the autocode
>>>>                         generated functions are not working properly?
>>>>                  They are
>>>>                         compiled with sparc-rtems-gcc, as the main code.
>>>>
>>>>                         2) Are there any special flags needed to be
>>>>                  passed to the
>>>>                         compiler in order to link other libraries? Or
>>>>                  some rtems
>>>>                         configuration..
>>>>
>>>>                     Is there any chance it is printing floating point
>>>>                  numbers from a
>>>>                     non-FP task?
>>>>
>>>>
>>>>                         Best,
>>>>                         JM
>>>>
>>>>
>>>>
>>>>                     --     Joel Sherrill, Ph.D.             Director
>>>>                  of Research&   Development
>>>>                     joel.sherrill at OARcorp.com
>>>>                  <mailto:joel.sherrill at OARcorp.com>         On-Line
>>>>                  Applications Research
>>>>                     Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>>                       Support Available             (256) 722-9985
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>              --
>>>>              Joel Sherrill, Ph.D.             Director of Research&
>>>>               Development
>>>>              joel.sherrill at OARcorp.com
>>>>              <mailto:joel.sherrill at OARcorp.com>         On-Line
>>>>              Applications Research
>>>>              Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>>                Support Available             (256) 722-9985
>>>>
>>>>
>>>>
>>>>
>>>>          _______________________________________________
>>>>          rtems-users mailing list
>>>>          rtems-users at rtems.org<mailto:rtems-users at rtems.org>
>>>>          http://www.rtems.org/mailman/listinfo/rtems-users
>>>>          
>>>
>>>      _______________________________________________
>>>      rtems-users mailing list
>>>      rtems-users at rtems.org<mailto:rtems-users at rtems.org>
>>>      http://www.rtems.org/mailman/listinfo/rtems-users
>>>        
>>
>>
>>      _______________________________________________
>>      rtems-users mailing list
>>      rtems-users at rtems.org<mailto:rtems-users at rtems.org>
>>      http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>      
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        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