This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |