which gcc version?

Hi
I am getting linker error "undefined reference to __divdi3".
This is because c = a/b; where a,b,c are of type "long long" I understand this is gcc problem.
I am doing this on a pentium with gcc -v = egcs-2.91.66

Thanks for all the help.

Manoj

Don't do it in the kernel. It has nothing to gcc version.

hi

Addition and subtraction works fine. The problem is with multiplication and division. I am doing this to avoid floating point calculation and doing fixed point calculation. The rage is large enough to need "long long" Any other way to achieve this?

thanks
manoj

gcc requires a function call to do a mul/div on a long long. There is no easy way to do a 64bit op of this type on a 32 bit CPU...

IFF you are making a module that will never be part of the kernel tree you can get away with adding gcc -print-libgcc-file-name to your link line. And by that I mean:

	${LD} ${LDFLAGS} -o $@ $< `gcc -print-libgcc-file-name`

This is a hack that will link in the __div3 function from glibc into your module. NOTE that this will never be done for you in the kernel... so if you can don't use div or mul on long long.

Cheers,
Bart.

	WebSig: http://www.jukie.net/~bart/sig/

Actually there is -- presuming your CPU has lots of registers, which i386 does not have...

This rule -- "no -lgcc in kernel code" -- is to trap code which in fast-paths would call those slow routines. Fastpaths should either not grok such values, or at most use shifts.

To think of it, there really should be explicitely callable versions of these with LinuxKernel names for them, not gcc builtins.  That way people would *know* they are doing something, which is potentially very slow.
(And the API would not change from underneath them.)

/Matti Aarnio

Like include/asm-*/div64.h::do_div()?

--
dwmw2

Some, perhaps all, of the recent requirements for a 64 bit division can be handled with the (Intel) 32-bit division because only the dividend is 64 bits, and the division can be unsigned, i.e.

HIGHLONG = 0x08 ; Depends upon caller's stack.
LOWLONG = 0x0C
DIVISOR = 0x10

movl HIGHLONG(%esp), %edx
movl LOWLLONG(%esp), %eax
movl DIVISOR(%esp), %ecx
divl %ecx,%eax

... returns a longword in %eax

This could be an __inline__ function. Most other stuff can be reduced with shifts before a 32-bit divide.

64 bit signed division is a bitch in any 32-bit machine because it's done just line 4th grade long division. There are remainders that have to carried, etc.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

Like that (*) - but that has limited value spaces, the divider can be at most 32 bits, probably far less.

/Matti Aarnio

(*) Trying to recall when I, and few others, created that beast.
The divisor code in itself isn't mine, but the idea of supporting %Ld at printk() most definitely is..

How arbitrary is the divisor ?
Not by change a power-of-two ?

If it is arbitrary, how large ?
The printk() contains support routine doing longlong/int division when a) speed is *not* important, b) divisor is sufficiently small, and I think c) divisor is positive.

When you look at that code, you should begin to grasp, what kind of monster is the longlong/longlong code at -lgcc ... (and why gcc doesn't produce inline code for it.)

/Matti Aarnio

Which kernel are you using ?
GFS use this kind of computation. And with kernel 2.2, a module divdi3.o provides all missing symbol like __divdi3.

Christophe

Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com