Re: __divdi3 unresolved + X pointer blocks

Re: __divdi3 unresolved + X pointer blocks

[Kaoru Fukui]

From: Jean-Jacques Levy <Jean-Jacques.Levy@inria.fr>
To: linuxppc-dev@lists.linuxppc.org
Subject: __divdi3 unresolved + X pointer blocks
Date: Mon, 2 Jul 2001 16:31:55 -0400

>
> When compiling linux.2.4.6-pre6 (benh kernel), I get undefinded symbol
> __divdi3 in the fat.o module.  When I suppress module fat.o, kernel
> doesn't boot.  Please help! (My c-compiler is gcc-3.0-20010427pre_0a,
> libc is glibc-2.1.3-15f.)

Plaese update gcc-3.0 release or current gcc-3.0.1.pre from cvs.

I guess,our powerpc kernel doen't use __divdi3 ,
then I could not see the symbol when on top kernel source
I did
 grep -rn __divi3 *


Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Kaoru Fukui]

>I did
>grep -rn __divi3 *

Sorry my typo,

 I did
grep -rn __divdi3 *

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

__divdi3 unresolved + X pointer blocks

[Jean-Jacques Levy]

When compiling linux.2.4.6-pre6 (benh kernel), I get undefinded symbol
__divdi3 in the fat.o module.  When I suppress module fat.o, kernel
doesn't boot.  Please help! (My c-compiler is gcc-3.0-20010427pre_0a,
libc is glibc-2.1.3-15f.)

Second (disconnected) problem: when running X11 4.0.99.3
on my tibook with 2.4.5-pre3g4, the pointer is blocked when kde
starts. After snooze+wakeup, the pointer get unblocked and the
system works? Big thanks for any idea.

-JJ-

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Benjamin Herrenschmidt]

>
>Finally my kernel 2.4.6-pre6 (benh) still does not boot on my tibook
>but problem must be elsewhere now.

My current rsync should boot the tibook. Please give it a try using
the included .config and tell me, I plan to do a binary release of
that kernel.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[David Edelsohn]

>>>>> Jean-Jacques Levy writes:

Jean-Jacques> I installed gcc-3.0 release, and remained with my undefined
Jean-Jacques> __divdi3. Then I patched inode.c in fs/fat and replaced two divisions
Jean-Jacques> by 512 by >> 9. The error disapeared.

Jean-Jacques> Either gcc-3.0 has a bug, either there is a missing module to
Jean-Jacques> implement long divisions (by 512!) in fs/fat.o

	It might be that GCC is not optimizing this division as strongly
as it should.  __divdi3 is a 64-bit signed divide.  A signed divide is not
the same as a shift.  Maybe the 64-bit variable is not declared as
unsigned when it should be?

	The Linux kernel does not link against libgcc.a, so any GCC
support routines (such as __divdi3) need to be provided explicitly.

David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Kaoru Fukui]

From: David Edelsohn <dje@watson.ibm.com>
To: Jean-Jacques.Levy@inria.fr
Subject: Re: __divdi3 unresolved + X pointer blocks
Date: Wed, 04 Jul 2001 18:22:45 -0400
cc: k_fukui@highway.ne.jp, linuxppc-dev@lists.linuxppc.org

> >>>>> Jean-Jacques Levy writes:
>
> Jean-Jacques> I installed gcc-3.0 release, and remained with my undefined
> Jean-Jacques> __divdi3. Then I patched inode.c in fs/fat and replaced two
divisions
> Jean-Jacques> by 512 by >> 9. The error disapeared.
>
> Jean-Jacques> Either gcc-3.0 has a bug, either there is a missing module
to
> Jean-Jacques> implement long divisions (by 512!) in fs/fat.o
>
> 	It might be that GCC is not optimizing this division as strongly
> as it should.  __divdi3 is a 64-bit signed divide.  A signed divide is not
> the same as a shift.  Maybe the 64-bit variable is not declared as
> unsigned when it should be?
>
> 	The Linux kernel does not link against libgcc.a, so any GCC
> support routines (such as __divdi3) need to be provided explicitly.
>

I could compile kernel-2.4.6 using gcc-3.0.1pre without this problem.
So I will upload kernel-2.4.6 the makelog and gcc-3.0.1, later.
Let you know when I will upload the package done for JJ.
I believe  that gcc-3.0 also be able to compile the kernel with no problem.

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Kaoru Fukui]

From: Kaoru Fukui <k_fukui@highway.ne.jp>
To: David Edelsohn <dje@watson.ibm.com>, Jean-Jacques.Levy@inria.fr,Benjamin
Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: __divdi3 unresolved + X pointer blocks
Date: Thu, 5 Jul 2001 07:24:47 +0900
CC: linuxppc-dev@lists.linuxppc.org

>
> I could compile kernel-2.4.6 using gcc-3.0.1pre without this problem.
> So I will upload kernel-2.4.6 the makelog and gcc-3.0.1, later.
> Let you know when I will upload the package done for JJ.
> I believe  that gcc-3.0 also be able to compile the kernel with no problem.

Sorry, compilation has done but I got also Unresolved symbols .

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[David Edelsohn]

	You do not seem to have understood my reply.  I will repeat the
important sentence:

	SHIFT IS NOT THE SAME AS DIVIDE FOR SIGNED INTEGERS.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Jean-Jacques Levy]

Kaoru,

I installed gcc-3.0 release, and remained with my undefined
__divdi3. Then I patched inode.c in fs/fat and replaced two divisions
by 512 by >> 9. The error disapeared.

Either gcc-3.0 has a bug, either there is a missing module to
implement long divisions (by 512!) in fs/fat.o

Finally my kernel 2.4.6-pre6 (benh) still does not boot on my tibook
but problem must be elsewhere now.

-JJ-

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Kernel crash with BenH' tree (was: Re: __divdi3...)

[Michel Lanners]

Hi all,

On   4 Jul, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>Finally my kernel 2.4.6-pre6 (benh) still does not boot on my tibook
>>but problem must be elsewhere now.
>
> My current rsync should boot the tibook. Please give it a try using
> the included .config and tell me, I plan to do a binary release of
> that kernel.

Leave out the Thermal Management then (like it's done in your .config):
that seems to be the culprit for the recently reported crashes on the
TiBook. Just compared your 2.4.6 with and without Thermal: it's quite
clear ;-)

Haven't looked at why that is so, however.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Geert Uytterhoeven]

On Wed, 4 Jul 2001, David Edelsohn wrote:
> 	You do not seem to have understood my reply.  I will repeat the
> important sentence:
>
> 	SHIFT IS NOT THE SAME AS DIVIDE FOR SIGNED INTEGERS.

Indeed. That's why you have `logical shift right' and `arithmetic shift right'.
The former inserts zeroes, the latter inserts a copy of the MSB.

Don't know from memory whether PPC has them...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Kaoru Fukui]

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: David Edelsohn <dje@watson.ibm.com>
Subject: Re: __divdi3 unresolved + X pointer blocks
Date: Thu, 5 Jul 2001 10:13:16 +0200 (CEST)
cc: Kaoru Fukui <k_fukui@highway.ne.jp>, Jean-Jacques.Levy@inria.fr,Benjamin
Herrenschmidt <benh@kernel.crashing.org>,linuxppc-dev@lists.linuxppc.org

> On Wed, 4 Jul 2001, David Edelsohn wrote:
> > 	You do not seem to have understood my reply.  I will repeat the
> > important sentence:
> >
> > 	SHIFT IS NOT THE SAME AS DIVIDE FOR SIGNED INTEGERS.
>
> Indeed. That's why you have `logical shift right' and `arithmetic shift right
'.
> The former inserts zeroes, the latter inserts a copy of the MSB.
>
> Don't know from memory whether PPC has them...
>

Thanks your explain.

I alway used them when Z80 Assmble probramming ,long long time ago -:)

Kaoru


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Holger Bettag]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

>
>
> On Wed, 4 Jul 2001, David Edelsohn wrote:
> > 	You do not seem to have understood my reply.  I will repeat the
> > important sentence:
> >
> > 	SHIFT IS NOT THE SAME AS DIVIDE FOR SIGNED INTEGERS.
>
> Indeed. That's why you have `logical shift right' and
> `arithmetic shift right'.
> The former inserts zeroes, the latter inserts a copy of the MSB.
>
> Don't know from memory whether PPC has them...
>
Yes, PowerPC has both; but some forms don't have their own opcodes, as they
are emulated with bitfield instructions.

And: 'arithmetic shift right' is _not_ the same as signed divide, because the
rounding of negative operands or results may differ.

  Holger


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[David Edelsohn]

>>>>> Holger Bettag writes:

Holger> And: 'arithmetic shift right' is _not_ the same as signed divide, because the
Holger> rounding of negative operands or results may differ.

	Exactly!  For a 32-bit operand, a signed divide by an exact power
of two is equivalent to:

srawi
addze

	For synthesized 64-bit operand, this is more complicated, which is
why GCC calls __divdi3 instead of open-coding it.

	Will all of the people posting INCORRECT information about logical
versus arithmetic shift and converting signed divide into shift, please
stop.  You are propagating bad information.

	If one converts a divide into a shift, one is assuming more
information than one has informed the compiler.

	This whole discussion thread is confusing two issues.  If one
wants GCC to produce a shift, one needs to write the code so that GCC
safely can convert the divide into a shift.  If the shift is not safe,
then the Linux kernel needs to provide __divdi3.

	The two suggestions of writing the divide as a shift and linking
with libgcc.a BOTH ARE WRONG.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Michael Schmitz]

> 	The two suggestions of writing the divide as a shift and linking
> with libgcc.a BOTH ARE WRONG.

I haven't seen anyone suggest we link the kernel with libgcc.a. Just 'the
kernel needs to provide __divdi3'. As in: the kernel needs to provide a
hell of a lot of libgcc.a stuff on the various architectures (ashldi3,
ashrdi3, lshrdi3 come to mind, m68k and sparc). It's been done for ages.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Jean-Jacques Levy]

Sorry for the delay, but presently I'm out of office.

I tried your config (or what I think is your config) with
2.4.6-pre6. It didn't boot. Open Firmware answer (called
by yaboot): DEFAULT CATCH! code = 300 %SRR0 01016cf8 $SRR! 00003030
I cannot decipher OF msgs.

Maybe it was not your config, because I erase it at some point. If
necessary I can mail it.

-JJ-

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: __divdi3 unresolved + X pointer blocks

[Kaoru Fukui]

> From: Jean-Jacques Levy <Jean-Jacques.Levy@inria.fr>
> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Subject: Re: __divdi3 unresolved + X pointer blocks

> 2.4.6-pre6. It didn't boot. Open Firmware answer (called
> by yaboot): DEFAULT CATCH! code = 300 %SRR0 01016cf8 $SRR! 00003030
> I cannot decipher OF msgs.

Hi! Ben and JJ.
I also got same problem at kernel-2.4.7.pre  boot  which kernel be compiled
with gcc-3.0.1cvs,
But I tried kenel compilation continusly with kernel-2.2.19
when it needed the patch.
So I could take bootable kernel-2.2.19 which using gcc-3.0.1cvs.
Please look  my dmesg

I think boot problem which is in the kernel-2.4.x's source.
Please look the problem in kernel-2.4.x.

My using gcc-3.0.1 here is
ftp://ftp.linuxppc.org/users/kfukui/glibc-2.2.x-room/RPMS/

Thanks
Kaoru

 ------ dmesg ----------------
device tree used 41060 bytes
Total memory = 256MB; using 1024kB for hash table (at c0400000)
Linux version 2.2.19-0a (root@g4mpKFUKUI) (gcc version 3.0.1 20010707 (prerelease))
 #1 Wed Jul 11 00:39:55 JST 2001
PMU driver initialized for Core99
xmon uses screen and keyboard
PCI bus 0 controlled by pci at f0000000
PCI buses 0..1 controlled by pci at f2000000
PCI bus 0 controlled by pci at f4000000
Uni-N revision: 8, KeyLargo revision: 3

------- the patch to kernel-2.2.19 --------
diff -urN base/kernel/sched.c fixed/kernel/sched.c
--- base/kernel/sched.c	Tue Jun 26 07:12:15 2001
+++ fixed/kernel/sched.c	Wed Jul 11 00:29:08 2001
@@ -49,7 +49,7 @@
 long tick = (1000000 + HZ/2) / HZ;	/* timer interrupt period */

 /* The current time */
-volatile struct timeval xtime __attribute__ ((aligned (16)));
+struct timeval xtime __attribute__ ((aligned (16)));

 /* Don't completely fail for HZ > 500.  */
 int tickadj = 500/HZ ? : 1;		/* microsecs */


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/