unresolved symbols __udivdi3 and __umoddi3

unresolved symbols __udivdi3 and __umoddi3

[simon]

I am writing a module and would like to perform arithmetic on long 
long variables. When I try to do this the module does not load due
to the unresolved symbols __udivdi3 and __umoddi3. I notice these
are normally defined in libc. Is there any way I can do this in a 
kernel module.

Many Thanks

Simon.
__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: unresolved symbols __udivdi3 and __umoddi3

[Andreas Dilger]

On Jan 25, 2002  06:31 -0000, simon@baydel.com wrote:
> I am writing a module and would like to perform arithmetic on long 
> long variables. When I try to do this the module does not load due
> to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> are normally defined in libc. Is there any way I can do this in a 
> kernel module.

Normally you do not need to do 64-bit arithmetic in the kernel.  You
normally use power-of-2 values, and then shift/mask to get the results
you want.

What is it exactly that you need to do?

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: unresolved symbols __udivdi3 and __umoddi3

[Richard B. Johnson]

On Fri, 25 Jan 2002,  wrote:

> I am writing a module and would like to perform arithmetic on long 
> long variables. When I try to do this the module does not load due
> to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> are normally defined in libc. Is there any way I can do this in a 
> kernel module.
> 
> Many Thanks
> 
> Simon.

Normally, in modules, the granularity is such that divisions can
be made by powers-of-two. In a 32-bit world, the modulus that you
obtain with umoddi3 (the remainder from a long-long, division) should
normally fit within a 32-bit variable. If you insist upon doing 64-bit
math in a 32-bit world, then you can either make your own procedures
and link them, of you can "appropriate" them from the 'C' runtime
library code, include them with your source, assemble, and link them
in.


Cheers,
Dick Johnson

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

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: unresolved symbols __udivdi3 and __umoddi3

[Tim Schmielau]

On Fri, 25 Jan 2002, Richard B. Johnson wrote:

> On Fri, 25 Jan 2002,  wrote:
>
> > I am writing a module and would like to perform arithmetic on long
> > long variables. When I try to do this the module does not load due
> > to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> > are normally defined in libc. Is there any way I can do this in a
> > kernel module.
> >
> > Many Thanks
> >
> > Simon.
>
> Normally, in modules, the granularity is such that divisions can
> be made by powers-of-two. In a 32-bit world, the modulus that you
> obtain with umoddi3 (the remainder from a long-long, division) should
> normally fit within a 32-bit variable. If you insist upon doing 64-bit
> math in a 32-bit world, then you can either make your own procedures
> and link them, of you can "appropriate" them from the 'C' runtime
> library code, include them with your source, assemble, and link them
> in.

If 64-bit arithmetics cannot be avoided, the do_div64() macro defined in
include/asm/div64.h comes in handy.
  mod = do_div((unsigned long) x, (long) y)
will set  x  to the quotient x/y  and  mod  to the remainder  x%y .

Tim

Re: unresolved symbols __udivdi3 and __umoddi3

[simon]

First of all I would like to thank all the people that responded to my 
mail. Unfortunately the numbers I am using are not restricted to 
powers of two so I could not simply shift the data. I have decided to 
use the div64.h solution and it seems to work well. 

I have looked at this header file and I do not understand the asm 
syntax. 

In particular the only x86 div instruction I know only returns a 32 bit 
div result. Because I don't understand the div64 header I cannot 
see how a 64 bit result is calculated.

I also tried this header in a regular application. This failed to return 
the modulus although it works in a module.

Is this asm syntax documented anywhere ? 

Thanks Again 

Simon.


On 25 Jan 2002, at 22:42, Tim Schmielau wrote:

> On Fri, 25 Jan 2002, Richard B. Johnson wrote:
> 
> > On Fri, 25 Jan 2002,  wrote:
> >
> > > I am writing a module and would like to perform arithmetic on long
> > > long variables. When I try to do this the module does not load due
> > > to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> > > are normally defined in libc. Is there any way I can do this in a
> > > kernel module.
> > >
> > > Many Thanks
> > >
> > > Simon.
> >
> > Normally, in modules, the granularity is such that divisions can
> > be made by powers-of-two. In a 32-bit world, the modulus that you
> > obtain with umoddi3 (the remainder from a long-long, division) should
> > normally fit within a 32-bit variable. If you insist upon doing 64-bit
> > math in a 32-bit world, then you can either make your own procedures
> > and link them, of you can "appropriate" them from the 'C' runtime
> > library code, include them with your source, assemble, and link them
> > in.
> 
> If 64-bit arithmetics cannot be avoided, the do_div64() macro defined in
> include/asm/div64.h comes in handy.
>   mod = do_div((unsigned long) x, (long) y)
> will set  x  to the quotient x/y  and  mod  to the remainder  x%y .
> 
> Tim
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: unresolved symbols __udivdi3 and __umoddi3

[Tim Schmielau]

> > If 64-bit arithmetics cannot be avoided, the do_div64() macro defined in
> > include/asm/div64.h comes in handy.
> >   mod = do_div((unsigned long) x, (long) y)
> > will set  x  to the quotient x/y  and  mod  to the remainder  x%y .
>
> I have looked at this header file and I do not understand the asm
> syntax.
>
> In particular the only x86 div instruction I know only returns a 32 bit
> div result. Because I don't understand the div64 header I cannot
> see how a 64 bit result is calculated.
>

Sorry, there are (platform-dependent) restrictions that I forgot to
mention. I think do_div(x,y) should work for all platforms if
y < 2^16 and x/y < 2^32, but I may stand corrected.

Actually, Momchil Velikov just pointed out that some archs only do 32 bit
divs in do_div64, where at least the C code from asm-parisc/div64.h
should be used.

Tim

Re: unresolved symbols __udivdi3 and __umoddi3

[Daniel Phillips]

On January 28, 2002 05:21 am,  wrote:
> First of all I would like to thank all the people that responded to my 
> mail. Unfortunately the numbers I am using are not restricted to 
> powers of two so I could not simply shift the data. I have decided to 
> use the div64.h solution and it seems to work well. 
> 
> I have looked at this header file and I do not understand the asm 
> syntax. 
> 
> In particular the only x86 div instruction I know only returns a 32 bit 
> div result. Because I don't understand the div64 header I cannot 
> see how a 64 bit result is calculated.

This particular macro can't do that.  However, 64bits/32bits = 64bits is
easily calculated with two 64/32 hardware divides, in assembly.

> I also tried this header in a regular application. This failed to return 
> the modulus although it works in a module.
> 
> Is this asm syntax documented anywhere ? 

It's painful, isn't it?  And no, I don't know where it's documented.

--
Daniel

Re: unresolved symbols __udivdi3 and __umoddi3

[Mark Zealey]

On Mon, Jan 28, 2002 at 08:17:06PM +0100, Daniel Phillips wrote:

> > I also tried this header in a regular application. This failed to return 
> > the modulus although it works in a module.
> > 
> > Is this asm syntax documented anywhere ? 
> 
> It's painful, isn't it?  And no, I don't know where it's documented.

I've had these docs for some time, can't remember where I got them from:
http://pkl.net/~mark/GCC_INLINE_ASM_HOWTO
http://pkl.net/~mark/rmiyagi-inline-asm.txt

They're quite good. the rest is experiance..

-- 

Mark Zealey
mark@zealos.org
mark@itsolve.co.uk

UL++++>$ G!>(GCM/GCS/GS/GM) dpu? s:-@ a16! C++++>$ P++++>+++++$ L+++>+++++$
!E---? W+++>$ N- !o? !w--- O? !M? !V? !PS !PE--@ PGP+? r++ !t---?@ !X---?
!R- b+ !tv b+ DI+ D+? G+++ e>+++++ !h++* r!-- y--

(www.geekcode.com)

Re: unresolved symbols __udivdi3 and __umoddi3

[Momchil Velikov]

>>>>> "Daniel" == Daniel Phillips <phillips@bonn-fries.net> writes:
>> Is this asm syntax documented anywhere ? 

Daniel> It's painful, isn't it?  And no, I don't know where it's documented.

It is documented in "Using and Porting GNU Compiler Collection"
http://gcc.gnu.org/onlinedocs/gcc-3.0.3/gcc_5.html#SEC103

Re: unresolved symbols __udivdi3 and __umoddi3

[Daniel Phillips]

On January 28, 2002 08:46 pm, Momchil Velikov wrote:
> >>>>> "Daniel" == Daniel Phillips <phillips@bonn-fries.net> writes:
> >> Is this asm syntax documented anywhere ? 
> 
> Daniel> It's painful, isn't it?  And no, I don't know where it's documented.
> 
> It is documented in "Using and Porting GNU Compiler Collection"
> http://gcc.gnu.org/onlinedocs/gcc-3.0.3/gcc_5.html#SEC103

I suppose we could dignify that with the term 'documentation'.  (To me, it 
reads more like a tutorial than a reference work, though as always I'm 
grateful to RMS and the FSF for having contributed this.  And the price can't 
be beat.)

Do you know where to find documentation for the assembly instructions 
themselves?

-- 
Daniel

Re: unresolved symbols __udivdi3 and __umoddi3

[Momchil Velikov]

>>>>> "Daniel" == Daniel Phillips <phillips@bonn-fries.net> writes:

Daniel> On January 28, 2002 08:46 pm, Momchil Velikov wrote:
>> >>>>> "Daniel" == Daniel Phillips <phillips@bonn-fries.net> writes:
>> >> Is this asm syntax documented anywhere ? 
>> 
Daniel> It's painful, isn't it?  And no, I don't know where it's documented.
>> 
>> It is documented in "Using and Porting GNU Compiler Collection"
>> http://gcc.gnu.org/onlinedocs/gcc-3.0.3/gcc_5.html#SEC103

Daniel> I suppose we could dignify that with the term 'documentation'.  (To me, it 
Daniel> reads more like a tutorial than a reference work, though as always I'm 
Daniel> grateful to RMS and the FSF for having contributed this.  And the price can't 
Daniel> be beat.)

Daniel> Do you know where to find documentation for the assembly instructions 
Daniel> themselves?

The appropriate place would be the processor's reference manual.

Re: unresolved symbols __udivdi3 and __umoddi3

[Horst von Brand]

Daniel Phillips <phillips@bonn-fries.net> said:

[...]

> Do you know where to find documentation for the assembly instructions 
> themselves?

Standard ia32 references, i.e., at Intel's website. Beware, it is some 500
pages PDF. But they (and standard PC assembly books) use the nearly
unreadable Intel syntax with operands the other way around, so this is much
less of a help than it could be.

Has anyone gotten a instruction listing (just instructions and short
description, not the whole other stuff in there), preferably in AT&T
syntax?
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: unresolved symbols __udivdi3 and __umoddi3

[Daniel Phillips]

On January 29, 2002 05:38 pm, Horst von Brand wrote:
> Daniel Phillips <phillips@bonn-fries.net> said:
> 
> [...]
> 
> > Do you know where to find documentation for the assembly instructions 
> > themselves?
> 
> Standard ia32 references, i.e., at Intel's website. Beware, it is some 500
> pages PDF. But they (and standard PC assembly books) use the nearly
> unreadable Intel syntax with operands the other way around, so this is much
> less of a help than it could be.

I was afraid somebody would say that.

I need look no further than the shelf at my right hand for a full set of 
Pentium documentation.  I do not consider that an adequate substitute for a 
document expressing the syntax of all machine instructions of a particular 
architecture in the GNU syntax.

The only excuse I can think of for not having such a document is "we're all 
so busy we couldn't write it, please use the Intel documentation".  Please 
don't suggest that we have no need for our own documentmentation, written in 
a form familiar to us.

> Has anyone gotten a instruction listing (just instructions and short
> description, not the whole other stuff in there), preferably in AT&T
> syntax?

Err, now I feel I wrote the above a little too strongly, but I'm not going to 
change it, because it was my initial reaction.  Yes, that's *exactly* what I 
want.

-- 
Daniel

Re: unresolved symbols __udivdi3 and __umoddi3

[Jeff Garzik]

On Wed, Jan 30, 2002 at 09:09:32AM +0100, Daniel Phillips wrote:
> I need look no further than the shelf at my right hand for a full set of 
> Pentium documentation.  I do not consider that an adequate substitute for a 
> document expressing the syntax of all machine instructions of a particular 
> architecture in the GNU syntax.
[...]
> > Has anyone gotten a instruction listing (just instructions and short
> > description, not the whole other stuff in there), preferably in AT&T
> > syntax?
> 
> Err, now I feel I wrote the above a little too strongly, but I'm not going to 
> change it, because it was my initial reaction.  Yes, that's *exactly* what I 
> want.

Then whip up a Perl script or somesuch, and generate that from the data
provided in binutils.

	Jeff

Re: unresolved symbols __udivdi3 and __umoddi3

[Jeff Garzik]

On Tue, Jan 29, 2002 at 05:38:50PM +0100, Horst von Brand wrote:
> Has anyone gotten a instruction listing (just instructions and short
> description, not the whole other stuff in there), preferably in AT&T
> syntax?

What is the AT&T syntax for short descriptions accompanying insns?

:)

	Jeff

Re: unresolved symbols __udivdi3 and __umoddi3

[Daniel Phillips]

On January 25, 2002 05:56 pm, Richard B. Johnson wrote:
> On Fri, 25 Jan 2002,  wrote:
> 
> > I am writing a module and would like to perform arithmetic on long 
> > long variables. When I try to do this the module does not load due
> > to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> > are normally defined in libc. Is there any way I can do this in a 
> > kernel module.
> > 
> > Many Thanks
> > 
> > Simon.
> 
> Normally, in modules, the granularity is such that divisions can
> be made by powers-of-two. In a 32-bit world, the modulus that you
> obtain with umoddi3 (the remainder from a long-long, division) should
> normally fit within a 32-bit variable. If you insist upon doing 64-bit
> math in a 32-bit world, then you can either make your own procedures
> and link them, of you can "appropriate" them from the 'C' runtime
> library code, include them with your source, assemble, and link them
> in.

Let's be clear on one thing.  There is nothing unnatural about
32bits * 32bits = 64bits or 64bits / 32bits = 32bits in a 32 bit world.
In fact, it is a rare architecture that does not support this directly
in hardware.  It may be awkward to express it in C, but since when has
that ever stopped us from using the best machine instructions for the
job?

Personally, I find the omission of these mixed size muldiv operations
from the kernel a great inconvenience.  Think 'multiply by a ratio'.
Yes, I know that by various posturings you can force most problems
that would be most naturally be expressed this way into some other
form, but several things suffer:

  - Readability
  - Efficiency
  - Code complexity
  - Code size

I think the argument I've seen most often presented against mixed
size muldiv operations goes something like 'I've never used them, so
why would anybody need them?'.  This just means that somebody hasn't
written very many kinds of programs, particularly the kind of code
we need to write if we are ever going to get the VM and IO
balancing code working properly.

-- 
Daniel

Re: unresolved symbols __udivdi3 and __umoddi3

[Arjan van de Ven]

Daniel Phillips wrote:
> 
> On January 25, 2002 05:56 pm, Richard B. Johnson wrote:
> > On Fri, 25 Jan 2002,  wrote:
> >
> > > I am writing a module and would like to perform arithmetic on long
> > > long variables. When I try to do this the module does not load due
> > > to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> > > are normally defined in libc. Is there any way I can do this in a
> > > kernel module.
> > >
> > > Many Thanks
> > >
> > > Simon.
> >
> > Normally, in modules, the granularity is such that divisions can
> > be made by powers-of-two. In a 32-bit world, the modulus that you
> > obtain with umoddi3 (the remainder from a long-long, division) should
> > normally fit within a 32-bit variable. If you insist upon doing 64-bit
> > math in a 32-bit world, then you can either make your own procedures
> > and link them, of you can "appropriate" them from the 'C' runtime
> > library code, include them with your source, assemble, and link them
> > in.
> 
> Let's be clear on one thing.  There is nothing unnatural about
> 32bits * 32bits = 64bits or 64bits / 32bits = 32bits in a 32 bit world.
> In fact, it is a rare architecture that does not support this directly
> in hardware.  It may be awkward to express it in C, but since when has
> that ever stopped us from using the best machine instructions for the
> job?
> 
> Personally, I find the omission of these mixed size muldiv operations
> from the kernel a great inconvenience.  

*cough* #include <asm/div64.h> *cough*

Re: unresolved symbols __udivdi3 and __umoddi3

[Daniel Phillips]

On January 28, 2002 12:10 pm, Arjan van de Ven wrote:
> Daniel Phillips wrote:
> > 
> > On January 25, 2002 05:56 pm, Richard B. Johnson wrote:
> > > On Fri, 25 Jan 2002,  wrote:
> > >
> > > > I am writing a module and would like to perform arithmetic on long
> > > > long variables. When I try to do this the module does not load due
> > > > to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> > > > are normally defined in libc. Is there any way I can do this in a
> > > > kernel module.
> > > >
> > > > Many Thanks
> > > >
> > > > Simon.
> > >
> > > Normally, in modules, the granularity is such that divisions can
> > > be made by powers-of-two. In a 32-bit world, the modulus that you
> > > obtain with umoddi3 (the remainder from a long-long, division) should
> > > normally fit within a 32-bit variable. If you insist upon doing 64-bit
> > > math in a 32-bit world, then you can either make your own procedures
> > > and link them, of you can "appropriate" them from the 'C' runtime
> > > library code, include them with your source, assemble, and link them
> > > in.
> > 
> > Let's be clear on one thing.  There is nothing unnatural about
> > 32bits * 32bits = 64bits or 64bits / 32bits = 32bits in a 32 bit world.
> > In fact, it is a rare architecture that does not support this directly
> > in hardware.  It may be awkward to express it in C, but since when has
> > that ever stopped us from using the best machine instructions for the
> > job?
> > 
> > Personally, I find the omission of these mixed size muldiv operations
> > from the kernel a great inconvenience.  
> 
> *cough* #include <asm/div64.h> *cough*

Thanks, it's a start, but it is half of what's needed at best.  A 32*32=64
mul is needed as well.  Also, the div you allude to is expressed in an
awkward form.  It's better than nothing, but it's far from as useful as it
could be.

I have a reasonably useful pair of operations constructed some time back,
which I'll offer if the thread doesn't heat up too much.

-- 
Daniel

Re: unresolved symbols __udivdi3 and __umoddi3

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

GFS uses (provide) a module which provides these symbols.
I don't know if this is still the case with their non-free software but
you can certainly find the last free GFS release.

You can have a look at 
   http://www.sistina.com
but I guess that if they provide a way to get the last free release this
will not be a easy to find link.

Or at
   http://www.opengfs.org

But IIRC these symbol were used only for the 2.2 kernel (that I assume
you are using?) and the support for 2.2 kernel was removed in the
opengfs fork.

Christophe

On Fri, Jan 25, 2002 at 06:31:10AM -0000, simon@baydel.com wrote:
> I am writing a module and would like to perform arithmetic on long 
> long variables. When I try to do this the module does not load due
> to the unresolved symbols __udivdi3 and __umoddi3. I notice these
> are normally defined in libc. Is there any way I can do this in a 
> kernel module.
> 
> Many Thanks
> 
> Simon.
> __________________________
> 
> Simon Haynes - Baydel 
> Phone : 44 (0) 1372 378811
> Email : simon@baydel.com
> __________________________
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Dogs believe they are human. Cats believe they are God.

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: unresolved symbols __udivdi3 and __umoddi3

[Christoph Hellwig]

In article <20020125170642.GG671@online.fr> you wrote:
> But IIRC these symbol were used only for the 2.2 kernel (that I assume
> you are using?) and the support for 2.2 kernel was removed in the
> opengfs fork.

No - OpenGFS 0.0.9x still needs them even on 2.4.
The next development series leading toward 0.2 will remove that
requirement by resturcturing all the code that currently uses
64bit arithmetics without any real need.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: unresolved symbols __udivdi3 and __umoddi3

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On Fri, Jan 25, 2002 at 07:53:38PM +0100, Christoph Hellwig wrote:
> In article <20020125170642.GG671@online.fr> you wrote:
> > But IIRC these symbol were used only for the 2.2 kernel (that I assume
> > you are using?) and the support for 2.2 kernel was removed in the
> > opengfs fork.
> 
> No - OpenGFS 0.0.9x still needs them even on 2.4.
> The next development series leading toward 0.2 will remove that
> requirement by resturcturing all the code that currently uses
> 64bit arithmetics without any real need.

Oh yes my mistake was that GFS for kernel 2.2 require a lfs patch and I
had in mind that it was this patch that requires 64bits arithmetics.
But this is definitevly not the case (otherwise this should be compiled
in the kernel and not as a module).

Then your module (divdi3.o I guess) is enough for the need of the
original poster of this thread.
But the best thing to do for him is to rewrite his module to avoid
these 64bits operations.

As a side note, I was a contributor for this part of GFS and Sistina
never contacted me to ask me to give them my right before their
relicensing. But perhaps they have dropped the ppc support.

Christophe

> 
> 	Christoph
> 
> -- 
> Of course it doesn't work. We've performed a software upgrade.

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Cats seem go on the principle that it never does any harm to ask for
what you want. --Joseph Wood Krutch

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]