Hello. Currently when fs/fat/inode.c is compiled with gcc-3.0.x, there
are to lines which will cause a __divdi3 call to be used. But on most
archs, there isn't currently a __divdi3 implementation in the kernel, so
FAT will no longer link (or load as a module). The easy fix (pointed
out by Andrew Morton) is to replace the divide by 512 with a shift right
by 9, which has the same effect but doesn't use a divide.
This is vs 2.4.18-pre3, but applies to 2.5.2-pre9 as well (and probably
pre10 too..)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
===== fs/fat/inode.c 1.10 vs edited =====
--- 1.10/fs/fat/inode.c Wed Nov 21 15:12:16 2001
+++ edited/fs/fat/inode.c Thu Jan 10 15:40:11 2002
@@ -406,7 +406,7 @@
}
inode->i_blksize = 1 << sbi->cluster_bits;
inode->i_blocks = ((inode->i_size + inode->i_blksize - 1)
- & ~(inode->i_blksize - 1)) / 512;
+ & ~(inode->i_blksize - 1)) >> 9;
MSDOS_I(inode)->i_logstart = 0;
MSDOS_I(inode)->mmu_private = inode->i_size;
@@ -952,7 +952,7 @@
/* this is as close to the truth as we can get ... */
inode->i_blksize = 1 << sbi->cluster_bits;
inode->i_blocks = ((inode->i_size + inode->i_blksize - 1)
- & ~(inode->i_blksize - 1)) / 512;
+ & ~(inode->i_blksize - 1)) >> 9;
inode->i_mtime = inode->i_atime =
date_dos2unix(CF_LE_W(de->time),CF_LE_W(de->date));
inode->i_ctime =
Tom Rini wrote:
>
> Hello. Currently when fs/fat/inode.c is compiled with gcc-3.0.x, there
> are to lines which will cause a __divdi3 call to be used. But on most
> archs, there isn't currently a __divdi3 implementation in the kernel, so
> FAT will no longer link (or load as a module). The easy fix (pointed
> out by Andrew Morton) is to replace the divide by 512 with a shift right
> by 9, which has the same effect but doesn't use a divide.
>
> This is vs 2.4.18-pre3, but applies to 2.5.2-pre9 as well (and probably
> pre10 too..)
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/
>
> ===== fs/fat/inode.c 1.10 vs edited =====
> --- 1.10/fs/fat/inode.c Wed Nov 21 15:12:16 2001
> +++ edited/fs/fat/inode.c Thu Jan 10 15:40:11 2002
> @@ -406,7 +406,7 @@
> }
> inode->i_blksize = 1 << sbi->cluster_bits;
> inode->i_blocks = ((inode->i_size + inode->i_blksize - 1)
> - & ~(inode->i_blksize - 1)) / 512;
> + & ~(inode->i_blksize - 1)) >> 9;
> MSDOS_I(inode)->i_logstart = 0;
> MSDOS_I(inode)->mmu_private = inode->i_size;
>
wow, I always assumed the compiler was smart enough to replace a "/ 512"
with a shift.
Jeff
--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery
On Thu, 10 Jan 2002, Jeff Garzik wrote:
>
> wow, I always assumed the compiler was smart enough to replace a "/ 512"
> with a shift.
It is, but there was a bug in the PPC machine description in 3.0.x
(x=0,1), or something. It's supposedly fixed in later gcc's.
Tom, which gcc version do you have? I thought the fix made it into 3.0.3
(and from other issues I suspect it's better to upgrade to that anyway for
kernel compilation).
Or is this some other problem (ie if you see this on non-ppc compilation,
holler, and we'll try to see what's up)
Linus
On Thu, Jan 10, 2002 at 08:29:56PM -0800, Linus Torvalds wrote:
>
> On Thu, 10 Jan 2002, Jeff Garzik wrote:
> >
> > wow, I always assumed the compiler was smart enough to replace a "/ 512"
> > with a shift.
>
> It is, but there was a bug in the PPC machine description in 3.0.x
> (x=0,1), or something. It's supposedly fixed in later gcc's.
>
> Tom, which gcc version do you have? I thought the fix made it into 3.0.3
> (and from other issues I suspect it's better to upgrade to that anyway for
> kernel compilation).
This was indeed on PPC (I tried x86 w/ the same package but it worked)
running gcc-3.0.3-1 (from Debian/sid). So it seems the fix didn't make
it into a release yet. I guess I'll go hunt down some compiler people
and get them to fix it.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Fri, 11 Jan 2002, Tom Rini wrote:
>
> This was indeed on PPC (I tried x86 w/ the same package but it worked)
> running gcc-3.0.3-1 (from Debian/sid). So it seems the fix didn't make
> it into a release yet. I guess I'll go hunt down some compiler people
> and get them to fix it.
I've seen the patch, so it definitely is fixed - rth posted it to the gcc
lists. But it may be that it only went into the development tree, or that
it happened after 3.0.3 was released.
Linus
On Fri, Jan 11, 2002 at 10:09:08AM -0800, Linus Torvalds wrote:
>
> On Fri, 11 Jan 2002, Tom Rini wrote:
> >
> > This was indeed on PPC (I tried x86 w/ the same package but it worked)
> > running gcc-3.0.3-1 (from Debian/sid). So it seems the fix didn't make
> > it into a release yet. I guess I'll go hunt down some compiler people
> > and get them to fix it.
>
> I've seen the patch, so it definitely is fixed - rth posted it to the gcc
> lists. But it may be that it only went into the development tree, or that
> it happened after 3.0.3 was released.
After talking with Franz Sirl abit (and reading the thread on the
patch), the fix is in the gcc-3.1 branch (so gcc-3.1.0 will work), and
the patch can be applied to 3.0.x (I've done it locally and am
rebuilding). He's going to try and get the patch applied to the 3.0.x
branch, but isn't sure if there will be another 3.0.x release with 3.1
coming out on april 15 (if on schedule).
So should we workaround this now in 2.4.x or no? There's other changes
which need to get into 2.4.x / 2.5.x anyhow for gcc-3.0.x to be happy on
all PPC arches anyhow. But I also get the feeling 2.4.x and gcc-3.1
will be unsupported/not a good idea for a while to come anyhow.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Fri, 11 Jan 2002, Tom Rini wrote:
>
> After talking with Franz Sirl abit (and reading the thread on the
> patch), the fix is in the gcc-3.1 branch (so gcc-3.1.0 will work), and
> the patch can be applied to 3.0.x
Ok.
> So should we workaround this now in 2.4.x or no?
I'll apply it to the 2.5.x tree - it's not as if it can hurt anything (it
will actually generate better code, as a signed divide is slightly more
complex than just a shift due to rounding issues, and gcc doesn't know
that the inode length will always be non-negative).
Whether it is worth working around in 2.4.x I don't have any real opinion
on, but I doubt it is worthwhile to compile 2.4.x with gcc-3.0.x anyway.
But again, applying it won't hurt.
Linus
On 11 January 2002 16:40, Linus Torvalds wrote:
> I'll apply it to the 2.5.x tree - it's not as if it can hurt anything (it
> will actually generate better code, as a signed divide is slightly more
> complex than just a shift due to rounding issues, and gcc doesn't know
> that the inode length will always be non-negative).
>
> Whether it is worth working around in 2.4.x I don't have any real opinion
> on, but I doubt it is worthwhile to compile 2.4.x with gcc-3.0.x anyway.
> But again, applying it won't hurt.
I don't consider kernel compilation as a developer-only activity:
we certainly don't expect Aunt Tillie to compile kernels, but it's expected
almost every server admin will want/need to do it.
Keeping two versions of GCC (one for 2.4 kernel, other for everyday use) is
something I don't like. Imagine what we will have around New Year 2003: 2.5
is still devel, 2.4 is stable, GCC 3.1+ is out and stable. Most people will
be glad to have 2.4 compilable by GCC 3.1 IMHO.
The fact that kernels compiled with GCC 3 are _bigger_ than ones compiled
with 2.96 is really annoys me. Will keep an eye on this as GCC 3 stabilize...
--
vda
On Thu, Jan 10, 2002 at 08:29:56PM -0800, Linus Torvalds wrote:
> It is, but there was a bug in the PPC machine description in 3.0.x
> (x=0,1), or something. It's supposedly fixed in later gcc's.
Apparently I only committed the patch to mainline. Oops.
r~