[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Soft Float for PC386
- Date: Wed, 14 Feb 2001 06:51:45 +1100
- From: angelo at hunterlink.net.au (Angelo Fraietta)
- Subject: Soft Float for PC386
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
PO Box 859
Hamilton NSW 2303
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)