[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NEWLIB and rtems[debugging report on i960KB]




Jae-Chul Moon wrote:
> 
> I had sent mail about newlib before and
> in that mail I had written that printf() was not working but write() was
> working well.

RTEMS owns write(), newlib owns printf().  If your newlib configuration
is wrong, then it won't work.  printf assumes more works.

> I found the reason why printf() function is not working
> and fixed that. And I have some question on that.

I believe you worked around the real problem.

> What I found is that struct _reent's memory layout in libc.a differ from
> memory layout of rtems image.

Then they were not built using the same copy of reent.h.  Which likely means
there is an inconsistency in the toolset somewhere.

> It is found by tracing deassembled code of libc.a and rtems test image.
> The code of newlibc.c of rtems not working with libc.a, perticularly at
> _REENT initialization part.
> 
> So, I elimiated the below code from libc_init() function in newlibc.c
> 
> _REENT = &libc_global_reent;
> 
> Then, printf() was working.

Are you sure you are using an i960-rtems configuration of newlib?

> Now, what I asking is that the libc.a is compiled not by target
> compiler(i960-rtems-gcc)
> but by host computer's gcc?
> If the libc.a is compiled by host computer's gcc, it maybe means
> binary uncompatability between host gcc and gcc for target.
> My host environment is redhet 5.3 for alpha and egcs 1.0.3

If you are not using the i960-rtems newlib configuration built as
part of the one-tree style build process, then all bets are off.

If you can even invoke printf, then it was not built by the host compiler.
 
> And another is that I found that newlibc is unnecessary code in the
> debugging
> because _REENT is not changed with task switch.
> Actually, codes that changing _REENT is written in libc_switch_hook()
> function but
> libc_switch_hook() is not called when task is switched.

Then the newlib extension is not being installed.  Very likely it is because
of this "back door" which disables C Library reentrancy support in
c/src/lib/libbsp/shared/bsplibc.c.

    /*
     * Set up for the libc handling.
     */

    if (BSP_Configuration.ticks_per_timeslice > 0)
        libc_init(1);                /* reentrant if possible */
    else
        libc_init(0);                /* non-reentrant */


> Jae-Chul Moon
> 
> Graduate school student
> School of Electronics and Electrical Engineering,
> Kyungpook National University, Korea
> e-mail : vgate at palgong.kyungpook.ac.kr

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985