Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Jun 2005 11:32:29 -0400
From:      Jung-uk Kim <jkim@niksun.com>
To:        =?utf-8?q?Jean-S=C3=A9bastien_P=C3=A9dron?= <jspedron@club-internet.fr>
Cc:        freebsd-amd64@freebsd.org, freebsd-ia64@freebsd.org, freebsd-alpha@freebsd.org, freebsd-ppc@freebsd.org
Subject:   Re: [CALL FOR TESTERS] ReiserFS on non-i386 hardware patch
Message-ID:  <200506021132.29814.jkim@niksun.com>
In-Reply-To: <429EFDC1.6040905@club-internet.fr>
References:  <429D860A.5000608@club-internet.fr> <20050602082615.GA36096@dragon.NUXI.org> <429EFDC1.6040905@club-internet.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 02 June 2005 08:38 am, Jean-Sébastien Pédron wrote:
> David O'Brien wrote:
> > On Wed, Jun 01, 2005 at 06:33:12PM -0400, Jung-uk Kim wrote:
> >>The kernel module doesn't load because of an amd64-specific GCC
> >> 3.4 optimization bug.  To work around:
> >>
> >>Index: Makefile
> >>=================================================================
> >>== RCS file: /home/ncvs/src/sys/modules/reiserfs/Makefile,v
> >> retrieving revision 1.1
> >>diff -u -r1.1 Makefile
> >>--- Makefile    24 May 2005 12:30:13 -0000      1.1
> >>+++ Makefile    1 Jun 2005 22:22:52 -0000
> >>@@ -8,4 +8,8 @@
> >>        reiserfs_namei.c reiserfs_prints.c reiserfs_stree.c \
> >>        reiserfs_vfsops.c reiserfs_vnops.c
> >>
> >>+.if ${MACHINE_ARCH} == "amd64"
> >>+CFLAGS+=       -minline-all-stringops
> >>+.endif
> >>+
> >
> > Unfortunately we really don't like to put this type of CFLAGS in
> > non-*.mk files.

Yeah, I agree.  That's ugly.

> > Since we know the GCC 3.4.2 compiler bugs will be fixed, I suggest
> > we just document this issue and be happy that otherwise the code
> > is ready to go on FreeBSD/amd64. 

Will it be fixed?  That's good news.  Do you know if there's GCC PR?

> Thank you Jung-Ku and David for your feedback.
            -------
            Jung-uk ;-)

> Olivier Houchard could test it on amd64 too and found another
> workaround for this same issue.

Cool.  It's good to hear that it was found.

> The problem come from this macro: 
> #define	INITIALIZE_PATH(var)					\
>      struct path var = { ILLEGAL_PATH_ELEMENT_OFFSET, }
> where gcc generates a call to memset(). By replacing it with:
> #define	INITIALIZE_PATH(var)					\
>      struct path var;						\
>      bzero(&var);						\
       ------------
       bzero(&var, sizeof(struct path));

>      var.path_length = ILLEGAL_PATH_ELEMENT_OFFSET
> it works.

Yes, it works (after the above fix).

> I can add this (in favor of the CFLAGS workaround) and document it.
> When a fixed gcc will be in the tree, it'll be removed.

Please do so.

Thanks again,

Jung-uk Kim

> --
> Jean-Sébastien Pédron
> http://www.dumbbell.fr/
>
> PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506021132.29814.jkim>