[uClibc]0.9.19 mipsel floating point printf problem?

[Jon Loeliger]

> 
> Hi uClibc folks,

In the long standing tradition of replying to one's own mail,
I'll provide an update and continue a plea for insight...

> So, I've got a cross compiled (i386->mipsel) GCC 3.2.2 uClibc
> environment.  I've tried uClibc release 0.9.15, 0.9.19, and
> the current top of CVS tree as of an hour ago


> I originally thought I had a floating point issue, but now I'm
> not sure.  It could be a dynamic loader problem.

Now I think it is neither.  Perhaps it is now just a bug in printf().

> I think I have a linux 2.4.18 based on the IDT release with the
> Algorithmics FPU emulator 1.5 built into it

 
> My test program has been this trivial program:
> 
>     float a = 1.0, b = 5.0;
> 
>     printf("Hello\n");
>     f = a / b;
>     printf("f is now %g\n", f);

Minor extensions to this program indicate that the only real problem
is with the %f and %g formats of printf().

> Do we know if the FP linkage between the kernel/Algorithmics code
> and the uClibc 0.9.19 libraries is consistent?

I believe this is working now.  I have a program that makes a union
of a float and an int.  I then do float math into the union and
print it out as an integer hex value an it looks like happy ieee754
bit patterns.  But if I print it with %f or %g it dies.

I am fairly certain that my version of printf() should be supporting
floating point values.  So I guess one question would be what happens
when one tries to print a floating point format when
__STDIO_PRINTF_FLOAT
manages to become undefined?  (Hmmm.  Obvious C preprocessor
experiment coming up...)

So, are there any known issues with, say, PTHREADS and printf()?
Reentrancy issues?  I fixed an mmap on the mips, but are there
lingering malloc() problems, perhaps?

Thanks,
jdl