newlib on powerpc-eabi with soft-float

[Kai Ruottu]

Christopher Jenkins wrote:
> 
> Thanks, I followed your advice and added all the verbosity flags I could
> find to my AIX hosted build. The crucial piece of information that it gave
> me was the following:
> 
> attempt to open /usr/toolchain/..../nof/libgcc.a succeeded
> 
> So the correct libgcc.a *was* being found by the linker on my AIX box but,
> unlike my windows/cygwin hosted build, I was still getting a whole load of
> unresolved symbol errors (unable to find functions like __muldf3 and
> friends). On a hunch, I decided to copy the libgcc.a file from my windows
> machine onto my AIX machine... the result was that the build now worked
> perfectly. I therefore conclude that there is something wrong with the
> libgcc.a that I built on my AIX machine. Any advice on how to test whether
> it is corrupted etc?

 The 'powerpc-eabi-nm libgcc.a | more' to show the symbol names and the
'powerpc-eabi-ar tv libgcc.a | more' to show the object sizes in the archive
can be used to look inside it... The 'powerpc-eabi-objdump -dr libgcc.a | more'
can be used to see the disassembly... These should be the usual ones.

 The produced libgcc.a's and all other libraries too should be identical on
different hosts if produced from the same sources using the same version of
binutils and GCC... If not, something doesn't work. So what you did was the
right thing as a workaround, but why the build on AIX produced a corrupted
'libgcc.a' is weird. Anyway if one has the possibility to produce the same
libs on different hosts, that brings a good opportunity to a quick realiability
check, comparing the library sizes is the first quick check, then using 'cmp'
etc. to compare the binaries themselves...

 That the build/run host had the same CPU as the target may have somehow mislead
the configure and the existence of the FPU being forced everywhere, so those
calls to the basic 'fadd/fsub/fdiv/fmul' and 'dadd/dsub/ddiv/dmul' (with
different names in GCC) etc. were replaced with opcodes for the FPU. If there
would be a logfile from the GCC-build, that could tell something...

 BTW, I saw in my archives that you used gcc-2.95.3 and the 'ppc-eabi' target in it
still produced the monolithic 'fp-bit.o' and 'dp-bit.o' for the basic float/double
operations. Unless something like the Bill Gatliff's FAQ has put you to fix the
'gcc/config/rs6000/t-ppccomm', your 'libgcc.a's have these big objects. Doing the
fix now would serve as a 'good reason' to do a rebuild for the 'libgcc.a's, and to
get the necessary logfile from the build to tell what on earth happened there...

 Anyhow the start of this 'target makefile fragment' should be:

------------------------ clip --------------------------------------
# Common support for PowerPC eabi, System V targets.

# Do not build libgcc1.
LIBGCC1 =
CROSS_LIBGCC1 =

# These are really part of libgcc1, but this will cause them to be
# built correctly, so... [taken from t-sparclite]
LIB2FUNCS_EXTRA = eabi.S eabi-ctors.c tramp.S

FPBIT = fp-bit.c
DPBIT = dp-bit.c

dp-bit.c: $(srcdir)/config/fp-bit.c
	cat $(srcdir)/config/fp-bit.c > dp-bit.c

fp-bit.c: $(srcdir)/config/fp-bit.c
	echo '#define FLOAT' > fp-bit.c
	cat $(srcdir)/config/fp-bit.c >> fp-bit.c
------------------------ clip --------------------------------------

 The 'FPBIT =' and 'DPBIT =' force the build to split the 'fp-bit.o' and 'dp-bit.o'
into separate '.o's for every function, ie. to get a 'fine grained' soft-float
implementation. The capability to do this was included with gcc-2.95.3 but forgotten
to use for 'ppc-eabi'... With the fine-grained implementation only the needed soft-
float functions will be linked to the executable, not the big 'fp-bit.o' and 'dp-bit.o'.

 With a simple test:

------------------------ clip --------------------------------------
H:\usr\local\samples>type fp-test.c
#include <stdio.h>

int main(void)
{
   float a;
   float b;
   double c;
   double d;

   a = 3.14159;
   b = 2.7183;
   c = (double) a;
   d = (double) b;

   a = a + b;
   a = a * b;
   c = c - d;
   c = c / d;

   return 1;
}
------------------------ clip --------------------------------------

I got with the original 'nof/libgcc.a' and with the 'fine grained' one:

------------------------ clip --------------------------------------
H:\usr\local\samples>e:\usr\local\ppc-eabi\bin\size fp-ppc-eabi*.x
   text    data     bss     dec     hex filename
  14652    3180      44   17876    45d4 fp-ppc-eabi1.x
   9484    3172     204   12860    323c fp-ppc-eabi2.x
------------------------ clip --------------------------------------

 So a 5 kbyte saving in the code size. Sometimes it may matter, sometimes
not...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com