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 : [email protected]
__________________________
On Jan 25, 2002 06:31 -0000, [email protected] 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/
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.
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, [email protected] 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 : [email protected]
> __________________________
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
Dogs believe they are human. Cats believe they are God.
On Fri, Jan 25, 2002 at 07:53:38PM +0100, Christoph Hellwig wrote:
> In article <[email protected]> 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? <[email protected]>
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
In article <[email protected]> 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.
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
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
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*
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
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 [email protected]
> 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 : [email protected]
__________________________
> > 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
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
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
[email protected]
[email protected]
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--
(http://www.geekcode.com)
>>>>> "Daniel" == Daniel Phillips <[email protected]> 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
On January 28, 2002 08:46 pm, Momchil Velikov wrote:
> >>>>> "Daniel" == Daniel Phillips <[email protected]> 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
>>>>> "Daniel" == Daniel Phillips <[email protected]> writes:
Daniel> On January 28, 2002 08:46 pm, Momchil Velikov wrote:
>> >>>>> "Daniel" == Daniel Phillips <[email protected]> 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.
Daniel Phillips <[email protected]> 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
On January 29, 2002 05:38 pm, Horst von Brand wrote:
> Daniel Phillips <[email protected]> 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
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
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