Well, i'm using regular printf. I would not point to the encoding since it allways prints the same thing no matter what i pass to printf().<br><br>I removed the 3 optimization in the gcc flags and removed the other ones and the same problem occurs. If i remove the printf the application exits on the following instruction<br>
<br>IU in error mode (tt = 0x2b)<br> 4000ca8c  d127bfec   st  %f8, [%fp - 0x14]<br><br>. I'm initializing rtems with:<br><br>#define CONFIGURE_INIT<br>#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER<br>#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER<br>
<br>#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 10<br>#define CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE (300*1024)<br><br>#define CONFIGURE_MAXIMUM_POSIX_THREADS             10<br>#define CONFIGURE_MAXIMUM_POSIX_MUTEXES                10<br>
#define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES            5<br><br>#define CONFIGURE_POSIX_INIT_THREAD_TABLE<br><br>I think i have enough stack space. <br>Also, if i point CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT  to a function declared on the autocode the printfs do not work well, which does not happen if i point it to a function declared on the main code. <br>
<br>The autocode is compiled with sparc-rtems-gcc and a library libgnc.a is created which is then passed to the compiler at link time with -lgnc. The library is created with<br><br>ar ruvs libgnc.a *.o<br><br>Does it make sense that there may be a problem with the compiled .o's of the library? If so, how can its declared functions be messing up with memory operations and not on the main code? They use the same compiler..<br>
<br><br>Best,<br>JM<br><br><div class="gmail_quote">On Thu, Jun 17, 2010 at 4:18 AM, Ralf Corsepius <span dir="ltr"><<a href="mailto:ralf.corsepius@rtems.org">ralf.corsepius@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On 06/16/2010 07:48 PM, João Rasta wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yes, here goes<br>
<br>
// dummy printf test code<br>
int upa(void)<br>
{<br>
     int i = 0;<br>
<br>
     for (i=0; i<  20; i++)<br>
         printf("B\n");<br>
<br>
     exit(0);<br>
<br>
}<br>
<br>
And the result is:<br>
<br>
<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
     ¬ÖUf<br>
<br>
Program exited normally.<br>
</blockquote></div></div>
Hmm, I am seeing "4 characters per line" instead of "1 or 2 characters per line" as one would expect.<br>
<br>
Are you sure your code uses the right printf? 4 chars instead of 1 could indicate using UTF8 or UTF16 encoding instead of ACSII.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
sparc-rtems-gcc -c -O3 -g3 -ffloat-store -fPIC   -DUSE_RTMODEL -DMODEL=gnc<br>
-DRT -DNUMST=1 -DTID01EQ=0 -DNCSTATES=0 -DUNIX -DMT=0 -DHAVESTDI<br>
O   -I. -I../../rtwlt/matlab/simulink/include<br>
-I../../rtwlt/matlab/extern/include -I../../rtwlt/matlab/rtw/c/src<br>
-I../../rtwlt/matlab/rtw/c/<br>
src/ext_mode/common -I. -I.. -I../../rtwlt/matlab/rtw/c/libsrc<br>
../../rtwlt/matlab/rtw/c/src/rt_sim.c<br>
</blockquote>
<br></div>
... -O3 -g3 -ffloat-store -fPIC<br>
certainly leave room for speculation on incompatibility.<br>
<br>
-03 ... switches on dangerous optimizations<br>
-ffloat-store ... could be incompatible to rtems-gcc/newlib<br>
-fPIC ... unneeded, unused by the rtems-toolchains, unknown<br>
   side effects on rtems-gcc/newlib<br><font color="#888888">
<br>
Ralf<br>
</font></blockquote></div><br>