Hi,
I finally found out the cause of the problem that prevented us to remove our copy of libgcc. The problem was that when switching to the libgcc provided by GCC, there would be strange crashes. The cause of these crashes is that the libgcc shipped with GCC is compiled with default options, in Sparc64 case the machine model is 'embmedany'. This makes memory accesses use %g4 as base register and since we don't initialize it (because other code uses machine model 'medany'), there will be crashes due to random base with some memory accesses in libgcc. It's clear that the default machine model for Sparc64 is not compatible with OpenBIOS, as is any libgcc compiled with this model.
I also found out how to make GCC compile and use separate libgccs ('multilib') for each machine model. This is enabled for sparc64-elf target case with the following patch (applies to gcc-4.6-20100925). --- gcc/config/sparc/t-crtfm.orig 2002-06-20 18:00:02.000000000 +0000 +++ gcc/config/sparc/t-crtfm 2010-10-03 14:45:31.000000000 +0000 @@ -1,4 +1,11 @@ EXTRA_PARTS += crtfastmath.o
+MULTILIB_OPTIONS = mcmodel=medany/mcmodel=medmid/mcmodel=medlow +MULTILIB_DIRNAMES = medany medmid medlow +MULTILIB_MATCHES = + +LIBGCC = stmp-multilib +INSTALL_LIBGCC = install-multilib + $(T)crtfastmath.o: $(srcdir)/config/sparc/crtfastmath.c $(GCC_PASSES) $(GCC_FOR_TARGET) $(MULTILIB_CFLAGS) $(LIBGCC2_CFLAGS) -c -o $(T)crtfastmath.o $(srcdir)/config/sparc/crtfastmath.c
The correct configuration can be seen with this command: $ sparc64-elf-gcc --print-multi-lib .; medany;@mcmodel=medany medmid;@mcmodel=medmid medlow;@mcmodel=medlow $ sparc64-elf-gcc -v Using built-in specs. COLLECT_GCC=sparc64-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc64-elf/4.6.0/lto-wrapper Target: sparc64-elf Configured with: ../configure --target=sparc64-elf --enable-targets=sparc64-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --enable-multilib Thread model: single gcc version 4.6.0 20100925 (experimental) (GCC)
With this version, openbios-sparc64 without our local libgcc works as well as the old version.
It may also be possible to change the default machine model, but I didn't try that. This way may be easier if the GCC is not new enough to support multilib.
Now the big question is, should we still aim for removal? I'm not sure if libgccs shipped with native GCCs are compatible. Requiring a specifically patched GCC does not seem so attractive, though most people probably make a cross compiler anyway.
Hi,
Am 03.10.2010 um 17:59 schrieb Blue Swirl:
I finally found out the cause of the problem that prevented us to remove our copy of libgcc. The problem was that when switching to the libgcc provided by GCC, there would be strange crashes. The cause of these crashes is that the libgcc shipped with GCC is compiled with default options, in Sparc64 case the machine model is 'embmedany'. This makes memory accesses use %g4 as base register and since we don't initialize it (because other code uses machine model 'medany'), there will be crashes due to random base with some memory accesses in libgcc. It's clear that the default machine model for Sparc64 is not compatible with OpenBIOS, as is any libgcc compiled with this model.
[snip]
I tried compiling RTAS with $(CC) and -lgcc as in your patch, but it fails to link with an undefined symbol _savegpr_31. That's one of those in crtsavres.S. Any idea? The patched sparc64 gcc seemed only necessary for runtime crashes iiuc.
Andreas
Am 03.10.2010 um 17:59 schrieb Blue Swirl:
Now the big question is, should we still aim for removal? I'm not sure if libgccs shipped with native GCCs are compatible. Requiring a specifically patched GCC does not seem so attractive, though most people probably make a cross compiler anyway.
What about submitting your patch upstream to GCC? 4.6.0 is still in "Stage 1, open for development." Maybe include a script that builds the necessary cross-compiler(s) to an OpenBIOS-private directory?
Did you do any testing outside sparc64? If yes, any other GCC patches would we handy.
Andreas
On Sat, Oct 16, 2010 at 3:55 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 03.10.2010 um 17:59 schrieb Blue Swirl:
Now the big question is, should we still aim for removal? I'm not sure if libgccs shipped with native GCCs are compatible. Requiring a specifically patched GCC does not seem so attractive, though most people probably make a cross compiler anyway.
What about submitting your patch upstream to GCC? 4.6.0 is still in "Stage 1, open for development." Maybe include a script that builds the necessary cross-compiler(s) to an OpenBIOS-private directory?
That may be useful, there have been frequent questions about cross-compiler setup.
Did you do any testing outside sparc64? If yes, any other GCC patches would we handy.
I tried to get a powerpc64-elf compiler (with the patches I sent earlier), but I didn't succeed.