rtems with matlab autocode problems

[Donald Locker]

Is libgnc.a using its own private printf?  What functions does libgnc.a contain and expose to the outside world?  ("nm -n libgnc.a" should tell you all that.)  I'm thinking it is not using the RTEMs library function.  If the librarian includes [portions of] a printf implementation that is incompatible with the RTEMs printf, there could be trouble.

HTH,
Donald.
--
Donald H Locker, Sr. Software Engineer
Solidica, Inc.
1194 Oak Valley Dr, Suite 80
Ann Arbor, MI  48108

email: donald.locker at solidica.com
vox: 734 222 4680 x132
fax: 734 222 4681

From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] On Behalf Of João Rasta
Sent: Thursday, June 17, 2010 5:33 AM
To: Ralf Corsepius
Cc: rtems-users at rtems.com
Subject: Re: rtems with matlab autocode problems

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().

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

IU in error mode (tt = 0x2b)
 4000ca8c  d127bfec   st  %f8, [%fp - 0x14]

. I'm initializing rtems with:

#define CONFIGURE_INIT
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 10
#define CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE (300*1024)

#define CONFIGURE_MAXIMUM_POSIX_THREADS             10
#define CONFIGURE_MAXIMUM_POSIX_MUTEXES                10
#define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES            5

#define CONFIGURE_POSIX_INIT_THREAD_TABLE

I think i have enough stack space. 
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. 

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

ar ruvs libgnc.a *.o

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..


Best,
JM
On Thu, Jun 17, 2010 at 4:18 AM, Ralf Corsepius <ralf.corsepius at rtems.org> wrote:
On 06/16/2010 07:48 PM, 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.
Hmm, I am seeing "4 characters per line" instead of "1 or 2 characters per line" as one would expect.

Are you sure your code uses the right printf? 4 chars instead of 1 could indicate using UTF8 or UTF16 encoding instead of ACSII.

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

... -O3 -g3 -ffloat-store -fPIC
certainly leave room for speculation on incompatibility.

-03 ... switches on dangerous optimizations
-ffloat-store ... could be incompatible to rtems-gcc/newlib
-fPIC ... unneeded, unused by the rtems-toolchains, unknown
  side effects on rtems-gcc/newlib

Ralf