Question regarding libm

Manuel Novoa III mjn3 at codepoet.org
Thu Sep 29 23:18:51 UTC 2005


On Thu, Sep 29, 2005 at 10:02:06PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2005-09-29 13:39:21 -0600, Manuel Novoa III <mjn3 at codepoet.org> wrote:
> > On Thu, Sep 29, 2005 at 08:35:15PM +0200, Jan-Benedict Glaw wrote:
> > > I'm currently trying to resurrect the former port of uClibc to the VAX
> > > architecture.
> > > 
> > > So far, I've collected a number of patches for binutils, gcc and
> > > uClibc with allow me to compile libc and libm and link it all together
> > > (currently I can only manually link, I need to figure out how to make
> > > GCC emit a working collect1 call, but thats a different story).
> > > 
> > > I tried to play with libm and called sin(), just for fun, and got
> > > this:
> > > 
> > > [370436.240000] PID 78: starting thread pc=   10080 new_sp=7FA0CE90 regs->sp=7FF04BD0
> > > [370436.340000] Arithmetic Fault at PC=   12adb, Floating or Decimal Division by Zero Fault, (code=9)
> [...]
> 
> > > Debugging doesn't work at this time (dwarft2 emitting isn't working
> > > :-), but using objdump, it breaks in _fpmaxtostr().
> > > 
> > > >From a fast glance at the code, it seems to imply IEEE floating point
> > > representation, doesn't it? That would be somewhat bad, since VAX does
> > > have it's own numeric representation...
> > 
> > Currently, _fpmaxtostr() assumes a base 2 representation.  But there's
> > a compile-time test for that using FLT_RADIX.  Otherwise, it makes no
> > assumptions about internal representation of float.  It _does_ assume
> > some IEEE float behavior though.  If you could isolate the problem down
> > to a particular area of the code, I'd be happy to take a look.
> 
> I'll try to do that, though it's not exactly simple. (Debugging by
> disassembling and matching disassembly output with source code. Yay:-)

Wasn't asking you to go that far.  Just throw some output at stderr to
isolate the section of code involved.

Manuel



More information about the uClibc mailing list