The following is my original question about determining floating point
compile options when you only have the object file left.
>Does anyone know how to tell what kind of floating point option was used to
>compile a piece of source code by only looking at the object file that was
>created. I am trying to find if there is a floating-point 'magic' number
>(much like the file type'magic' number given in magic(5)).
>
>I've got some old .o files that I need to compile into some existing source
>code and I no longer have access to the original source code. What I want
>to do is write a program to pull appart the .o file and tell me if it was
>compiled with the -ffpa, -fswitch, etc.
>Tom Leach leach@oce.orst.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Many thanks to the following folks for their speedy replies!
frew%crseo@hub.ucsb.edu (Jim Frew)
bzs@world.std.com (Barry Shein)
mem@ece.ucsd.edu (Margaret Mikulska)
There is a program called "nm" (name-list) that will print the name list
(symbol table) of an object file. if you use the -u option nm will show
all of the undefined symbols in the object file. Since floating point
options are undefined until the link phase, you can determine how an object
file was compiled by looking for the following symbols:
undefined? compiled with
----------- -------------
f68881_used -f68881
ffpa_used -ffpa
Vadds -fswitch
Fadds -fsoft
(the Vadds or Fadds can be any float subroutine preceded by a V or F)
(ie; Vcos, Fpow10s, Fsqrts,...)
My problem was partly to determine the floating point option to compile with,
and also an undefined symbol. Here's what my F77 compile output looked
like:
f77 -ffpa eigcomp.f -o eigcomp -limsl
eigcomp.f:
MAIN:
ld: Undefined symbol
Fc_div
In this case, it turns out that the IMSL library was compiled under the
SunOS 3.5 operating system. This was the old version of the libraries which
are no longer supported under SunOS 4.0.3, so I thought that I'ld copy them
back to my new 4.0.3 system and give the people here both options. Well,
(if you haven't guessed by now) there is a difference in how 3.X and 4.X
define the complex floating point routines. In 3.X it's defined as a symbol
(Fc_div) and in 4.X it's defined as a subroutine (_Fc_div) (note the leading
underscore). The only routine that seems to have this problem is the
complex divide (but I really speculating here, I didn't exercise the other
routines, they just look semi-ok in the nm output. I had to tell the people
here who were using the complex routines and the old libaray to upgrade
their code to use the new library subroutines.
There is some documentation on floating point options in the following
Sun manuals.
Appendix G ("Assembly-level in-line expansion") in "FP programmer's guide".
"Floating-point programmer's guide addendum" (this SHOULD have come with
your 4.0.[13] documents, but I couldn't find mine.
In the process I wrote a quick shell script to figure out if a given
floating point routine is in any of the floating point libraries and if
so, which one.
#! /bin/csh
foreach i (f68881 ffpa fsoft fswitch)
echo " $i"
nm /lib/$i/libm.a | grep $1
echo ""
end
I used this to find where the V and F symbols were coming from. It may
be of some use to people, but most of it is not especially useful since
the compiler/linker is taking care of things at this level.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:56 CDT