[PATCH]: Fix fs modules on sparc64 build with newer gcc

[PATCH]: Fix fs modules on sparc64 build with newer gcc

[David Miller]

Newer versions of gcc emit references to libgcc internal
functions __bswapsi2 and __bswapdi2 when building ufs and
some other filesystem modules on sparc64.

Unfortunately older versions of gcc lack these symbols in
libgcc so we can't export them universally, we have to check
for it using configure link tests.

I commited this under the "trust dave with sparc stuff" rule.
Let me know if it that wasn't appropriate in this case :-)

I also rebuild configure when commiting these changes.

Thanks.

2009-04-11  David S. Miller  <davem@davemloft.net>

	* conf/sparc64-ieee1275.rmk (kernel_img_LDFLAGS): Link with
	static libgcc.
	* configure.ac: Check for __bswapsi2 and __bswapdi2 presence.
	* include/grub/sparc64/libgcc.h (__bswapsi2): Export libgcc
	function, if present.
	(__bswapdi2): Likewise.
---
 conf/sparc64-ieee1275.rmk     |    2 +-
 configure.ac                  |    2 +-
 include/grub/sparc64/libgcc.h |   12 ++++++++++++
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/conf/sparc64-ieee1275.rmk b/conf/sparc64-ieee1275.rmk
index 1658a66..f1fdb5b 100644
--- a/conf/sparc64-ieee1275.rmk
+++ b/conf/sparc64-ieee1275.rmk
@@ -81,7 +81,7 @@ kernel_elf_SOURCES = kern/sparc64/ieee1275/init.c kern/ieee1275/ieee1275.c \
 kernel_elf_HEADERS = grub/sparc64/ieee1275/ieee1275.h
 kernel_elf_CFLAGS = $(COMMON_CFLAGS)
 kernel_elf_ASFLAGS = $(COMMON_ASFLAGS)
-kernel_elf_LDFLAGS = -mno-app-regs -nostdlib -Wl,-N,-Ttext,0x200000,-Bstatic,-melf64_sparc
+kernel_elf_LDFLAGS = -mno-app-regs -nostdlib -Wl,-N,-Ttext,0x200000,-Bstatic,-melf64_sparc -static-libgcc -lgcc
 
 # Modules.
 #_linux.mod linux.mod
diff --git a/configure.ac b/configure.ac
index 134e0a3..69f9783 100644
--- a/configure.ac
+++ b/configure.ac
@@ -200,7 +200,7 @@ if test "$target_cpu"-"$platform" = i386-pc; then
 fi
 
 # Check for functions.
-AC_CHECK_FUNCS(posix_memalign memalign asprintf)
+AC_CHECK_FUNCS(posix_memalign memalign asprintf __bswapsi2 __bswapdi2)
 
 #
 # Check for target programs.
diff --git a/include/grub/sparc64/libgcc.h b/include/grub/sparc64/libgcc.h
index e30c717..4a6b619 100644
--- a/include/grub/sparc64/libgcc.h
+++ b/include/grub/sparc64/libgcc.h
@@ -16,4 +16,16 @@
  *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <config.h>
+
 void EXPORT_FUNC (memset) (void);
+
+#ifdef HAVE___BSWAPSI2
+typedef int SItype __attribute__ ((mode (SI)));
+SItype EXPORT_FUNC (__bswapsi2) (SItype);
+#endif
+
+#ifdef HAVE___BSWAPDI2
+typedef int DItype __attribute__ ((mode (DI)));
+DItype EXPORT_FUNC (__bswapdi2) (DItype);
+#endif
-- 
1.6.2.1.222.g570cc

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[Pavel Roskin]

On Sat, 2009-04-11 at 01:27 -0700, David Miller wrote:
> Newer versions of gcc emit references to libgcc internal
> functions __bswapsi2 and __bswapdi2 when building ufs and
> some other filesystem modules on sparc64.
> 
> Unfortunately older versions of gcc lack these symbols in
> libgcc so we can't export them universally, we have to check
> for it using configure link tests.
> 
> I commited this under the "trust dave with sparc stuff" rule.
> Let me know if it that wasn't appropriate in this case :-)

Actually, changes to configure.ac affect other users as well.  Users of
other architectures would have to run those checks.

I would try to use weak functions or something like that.  Failing that,
I would add a check for affected architectures only.  Even if that would
make the script longer, it would make it clear which architectures need
the check, which is probably a good idea.

> I also rebuild configure when commiting these changes.

I see that configure and config.h.in we built by different versions of
autoconf.  That's likely to break.

I would run autogen.sh and commit all changed files after examining the
changes.  As a courtesy to others, I install the same version of
Autoconf that the current configure script was generated with.

Adding or removing files means that DISTLIST will change.  That should
be committed as well.

Personally, I would remove all files generated by autogen.sh from the
repository.  But I don't want to do something that is inconvenient to
others.  The issue was discussed in the past and the decision was to
keep those files.

-- 
Regards,
Pavel Roskin

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[David Miller]

From: Pavel Roskin <proski@gnu.org>
Date: Sat, 11 Apr 2009 23:53:33 -0400

> On Sat, 2009-04-11 at 01:27 -0700, David Miller wrote:
>> Newer versions of gcc emit references to libgcc internal
>> functions __bswapsi2 and __bswapdi2 when building ufs and
>> some other filesystem modules on sparc64.
>> 
>> Unfortunately older versions of gcc lack these symbols in
>> libgcc so we can't export them universally, we have to check
>> for it using configure link tests.
>> 
>> I commited this under the "trust dave with sparc stuff" rule.
>> Let me know if it that wasn't appropriate in this case :-)
> 
> Actually, changes to configure.ac affect other users as well.  Users of
> other architectures would have to run those checks.

And what kind of problems would that cause?  The symbols would
not be found, the test wouldn't pass, and other platforms don't
use the resulting config.h defines as well.  Only the sparc64
build uses this stuff.

It seems entirely harmless.

> I would try to use weak functions or something like that.  Failing that,
> I would add a check for affected architectures only.  Even if that would
> make the script longer, it would make it clear which architectures need
> the check, which is probably a good idea.

I don't think that would work well, these are symbols we have to
export to modules.

And since as I described above the test and the config.h defines
are totally harmless to other targets, I don't see what the point
is in using a more complicated and indirect implementation.

>> I also rebuild configure when commiting these changes.
> 
> I see that configure and config.h.in we built by different versions of
> autoconf.  That's likely to break.
> 
> I would run autogen.sh and commit all changed files after examining the
> changes.  As a courtesy to others, I install the same version of
> Autoconf that the current configure script was generated with.
> 
> Adding or removing files means that DISTLIST will change.  That should
> be committed as well.

I always check the status of my tree after running autogen.sh so I
would take care of all of these things.

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[Pavel Roskin]

On Sun, 2009-04-12 at 00:58 -0700, David Miller wrote:

> > Actually, changes to configure.ac affect other users as well.  Users of
> > other architectures would have to run those checks.
> 
> And what kind of problems would that cause?  The symbols would
> not be found, the test wouldn't pass, and other platforms don't
> use the resulting config.h defines as well.  Only the sparc64
> build uses this stuff.

The only problem that it will slow down the configure script.

By the way, the checks for those functions should be done with the
target compiler, that is after the second occurrence of CC="$TARGET_CC"
in configure.ac.

> I always check the status of my tree after running autogen.sh so I
> would take care of all of these things.

OK, I don't want to search who did it.  I hope we'll get rid of this
annoyance soon.

-- 
Regards,
Pavel Roskin

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[David Miller]

From: Pavel Roskin <proski@gnu.org>
Date: Sun, 12 Apr 2009 17:19:42 -0400

> On Sun, 2009-04-12 at 00:58 -0700, David Miller wrote:
> 
>> > Actually, changes to configure.ac affect other users as well.  Users of
>> > other architectures would have to run those checks.
>> 
>> And what kind of problems would that cause?  The symbols would
>> not be found, the test wouldn't pass, and other platforms don't
>> use the resulting config.h defines as well.  Only the sparc64
>> build uses this stuff.
> 
> The only problem that it will slow down the configure script.

This is not a serious issue.  The configure run is very compact
and efficient and my changes aren't going to materially change
this in any way whatsoever.

> By the way, the checks for those functions should be done with the
> target compiler, that is after the second occurrence of CC="$TARGET_CC"
> in configure.ac.

Sure, I can fix that.

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[Pavel Roskin]

On Sun, 2009-04-12 at 18:05 -0700, David Miller wrote:

> > The only problem that it will slow down the configure script.
> 
> This is not a serious issue.  The configure run is very compact
> and efficient and my changes aren't going to materially change
> this in any way whatsoever.

I know.  Although my PowerMAC G3 is slow enough, and I would hate to see
it run checks it doesn't need.

> > By the way, the checks for those functions should be done with the
> > target compiler, that is after the second occurrence of CC="$TARGET_CC"
> > in configure.ac.
> 
> Sure, I can fix that.

Thanks!

-- 
Regards,
Pavel Roskin

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[David Miller]

From: Pavel Roskin <proski@gnu.org>
Date: Mon, 13 Apr 2009 01:06:49 -0400

> On Sun, 2009-04-12 at 18:05 -0700, David Miller wrote:
> 
>> > By the way, the checks for those functions should be done with the
>> > target compiler, that is after the second occurrence of CC="$TARGET_CC"
>> > in configure.ac.
>> 
>> Sure, I can fix that.
> 
> Thanks!

I've committed this fix.

Re: [PATCH]: Fix fs modules on sparc64 build with newer gcc

[Robert Millan]

On Sat, Apr 11, 2009 at 01:27:31AM -0700, David Miller wrote:
> --- a/configure.ac
> +++ b/configure.ac
> @@ -200,7 +200,7 @@ if test "$target_cpu"-"$platform" = i386-pc; then
>  fi
>  
>  # Check for functions.
> -AC_CHECK_FUNCS(posix_memalign memalign asprintf)
> +AC_CHECK_FUNCS(posix_memalign memalign asprintf __bswapsi2 __bswapdi2)
> [...]
> +#ifdef HAVE___BSWAPSI2
> +typedef int SItype __attribute__ ((mode (SI)));
> +SItype EXPORT_FUNC (__bswapsi2) (SItype);
> +#endif

Very nice.  I wish someone with a powerpc and some spare time would do the
same to include/grub/powerpc/libgcc.h ;-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."