This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.3.5 arm-elf .. which multilib for soft-float?
Richard Earnshaw wrote:
On Tue, 2004-11-02 at 12:24, Joel Sherrill wrote:
Richard Earnshaw wrote:
On Tue, 2004-11-02 at 00:21, Joel Sherrill wrote:
Hi,
It looks like btween gcc 3.3.3 and 3.3.5, the file config/arm/t-arm-elf
was reworked. I am getting linking errors which indicate that the
default libc.a is hard-float.
The gcc documentation states that -mhard-float is the default for the
compiler and I only see these libc.a's
-mhard-float has *never* been the default for the arm-elf
configuration. In fact, AFAIK the only supported configuration of gcc
on ARM that still uses the FPA hard-float format is Linux.
I rather suspected this because I didn't recall any RTEMS user CPU model
I had ever looked at having hard float.
But the gcc documentation states that hard-float is ALWAYS the default:
The documentation is out of date. There is a time when that was correct
for all the (then) supported configurations, but it's now far from the
truth.
Now things are becoming clearer. Can you correct the
soft-float/hard-float documentation? You understand the situation better.
Given all that, why can't I link code when I use the -msoft-float flag.
From your description, it is redundant but it results in a string
of link errors like this:
/../../arm-rtems4.7/bin/ld: failed to merge target specific data of file
/opt/rtems-4.7/lib/gcc-lib/arm-rtems4.7/3.3.5/libgcc.a(_pack_sf.o)
$ cat j.c
#include <math.h>
float f( float x)
{
return sin(x);
}
$ /opt/rtems-4.7/bin/arm-rtems4.7-gcc j.c -O2 -lm
# WORKS
$ /opt/rtems-4.7/bin/arm-rtems4.7-gcc -msoft-float j.c -O2 -lm
# FAILS with ERRORS
Ah! I suspect you are trying to link some object compiled with
-msoft-float with objects that were compiled with neither -msoft-float
nor -mhard-float explicitly mentioned on the command line. Gas assumes
(incorrectly in this case) that if you don't specify -msoft-float you
meant -mhard-float (the compiler makes the opposite assumption, but
fails to pass on this information).
That makes sense.
Another similar side issue we have seen in the RTEMS world is that
there often should be come cpp predefine set when you switch a
CPU CFLAG and sometimes there isn't. We have caught a number of these
over the past few years related to not being able to tell if
soft or hardware FP was selected.
It is important to make sure that gcc provides enough information for
libraries to tailor themselves to different multilibs. RTEMS uses
multilibs to distinguish CPU issues -- soft float/hard float,
instruction presence (m68k especially here), register layour (mips),
etc. Knowing the architectural variant correctly from the cpp
predefines is important.
Ralf's patch should fix that issue, since it always passes something to
the assembler; but you will have to rebuild any objects built without
his patch applied.
It's not a problem to rebuild everything -- we have the source. :)
Ralf... I will rebuild with your patch and follow up. With any luck,
we can beg Richard to review it and get things right on 3.3, 3.4 and the
head.
Ralf's patch addresses a similar side issue we have caught with RTEMS.
There should be come cpp predefine set when you switch a
CPU CFLAG and sometimes there isn't. We have caught a number of these
over the past few years related to not being able to tell if
soft or hardware FP was selected.
It is important to make sure that gcc provides enough information for
libraries to tailor themselves to different multilibs. RTEMS uses
multilibs to distinguish CPU issues -- soft float/hard float,
instruction presence (m68k especially here), register layour (mips),
etc. Knowing the architectural variant correctly from the cpp
predefines is important.
There are other libraries that make similar distinctions. I believe
the Standard C++ library is making pretty heavy use of multilib
distinguishing predefines in places.
R.
--joel