Soft Float for PC386

[Angelo Fraietta]

It definitely is a coprocessor instruction. I disassembled the file and got
 10ba8b: dd 45 f0              fldl   0xfffffff0(%ebp)
 which is a load  +1.0 to ST(0)

Joel Sherrill wrote:

> Ralf Corsepius wrote:
> >
> > Angelo Fraietta wrote:
> > >
> > > I have noticed during the configure stage of the script, the following is shown (this is from the ts_386 so
> > > it should be soft float)
> > > running /bin/sh ../../../../../RTEMS4.5.0ss/c/src/make/configure  --host=i386-rt
> > > ems --build=i586-pc-linux-gnu --target=i386-rtems --prefix=/opt/rtems --disable-
> > > hwapi --enable-multiprocessing --enable-cxx --enable-rdbg --disable-tests --disa
> > > ble-networking --enable-posix --disable-itron --with-target-subdir=i386-rtems --
> > > libdir=/opt/rtems/i386-rtems/lib --cache-file=.././config.cache --srcdir=../../.
> > >
> > > does libdir=/opt/rtems/i386-rtems/lib mean that it would be linking with the libraries in that directory
> > > instead of the soft-float directory?
> > No. libdir is used by autoconf and automake to specify the path to
> > the directory where libraries shall be install during "make
> > install".
> > Currently is not used at all by RTEMS,and therefore should not have
> > any influence at all.
> >
> > > Shouldn't that be /opt/rtems/i386-rtems/lib/soft-float ??
> > No. libdir can vary inside of the build tree and should better not
> > be passed manually to the toplevel configure script at all.
> >
> > However, there should neither be a need to set it, nor should having
> > set it have any effect on building RTEMS. (Warning: Future versions
> > of RTEMS probably will be using it.)
> >
> > > I copied the files from the soft-float directory to that directory but still had the same fault, i.e.
> > > exception 7.
> > >  Is there anywhere else I should be looking
> > You could try to isolate the location of the offending FPU-call
> > (find the caller, eg. by debugging paranoia.exe, disassembly,
> > linker-map analysis).
>
> My guess is that incorrectly/accidentally there is an FP instruction.
> It could be by linking against the wrong library, incorrect code
> generation, or simply a piece of code assuming an FPU.  Given the
> fault address, you can do an objdump on the executable and see
> what instruction is at that address.  Using the objdump and symbol
> table (nm), you can tell what routine the offending instruction is
> in.  That plus possible the output of linking with -v should be
> enough to figure out where to look.
>
> > > or am I off the track completely??
> > :)
> >
> > >
> > > angelo wrote:
> > >
> > > > Is it possible that the wrong libraries are being linked.
> > You might want to add -v to the linker invocation in your BSP's
> > make-exe (make/custom/<BSP>.cfg) and try to analyse the what it
> > reports for linking paranoia.exe.
> >
> > Ralf
> >
> > --
> > Ralf Corsepius
> > Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
> > (FAW)
> > Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> > mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
> > http://www.faw.uni-ulm.de
>
> --
> 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

--
Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page

http://users.hunterlink.net.au/~maaaf/

There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
    Bernard of Clairvaux (1090 - 1153)