from where comes "__moddi3"?

from where comes "__moddi3"?

[Robert P. J. Day]

  again, probably displaying my abject ignorance, but i wrote a
trivial module that tries to "var % 15", and i get:

  WARNING: "__moddi3" undefined!

and, not surprisingly, when i try to insmod:

  insmod: error inserting 'seq.ko': -1 Unknown symbol in module

(using 16 rather than 15 works fine, as i assume that the modulus
call is simply replaced by an optimized  bitwise comparison.)

  so ... from where comes __moddi3?  i know there are places in the
kernel source tree that do non-power-of-2 moduli, and they work fine,
no?  thanks.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: from where comes "__moddi3"?

[Peter Zijlstra]

On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
> again, probably displaying my abject ignorance, but i wrote a
> trivial module that tries to "var % 15", and i get:
> 
>   WARNING: "__moddi3" undefined!
> 
> and, not surprisingly, when i try to insmod:
> 
>   insmod: error inserting 'seq.ko': -1 Unknown symbol in module
> 
> (using 16 rather than 15 works fine, as i assume that the modulus
> call is simply replaced by an optimized  bitwise comparison.)
> 
>   so ... from where comes __moddi3?  i know there are places in the
> kernel source tree that do non-power-of-2 moduli, and they work fine,
> no?  thanks.

let me guess, 32 bit kernel, and var is 64 bit?

gcc translates that into a libgcc call, which we _explicitly_ do not
have because 64bit divisions are expensive!

use do_div().

16 works because gcc translates that into a right shift.

Re: from where comes "__moddi3"?

[Alexander Shishkin]

On 7/21/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
>
>   again, probably displaying my abject ignorance, but i wrote a
> trivial module that tries to "var % 15", and i get:
>
>   WARNING: "__moddi3" undefined!
...which comes from libgcc1 which you obviously don't want to link against.

Does (var & 0x0f) not work for you?

Regards,
-- 
Alex

Re: from where comes "__moddi3"?

[Robert P. J. Day]

On Sat, 21 Jul 2007, Peter Zijlstra wrote:

> On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
> > again, probably displaying my abject ignorance, but i wrote a
> > trivial module that tries to "var % 15", and i get:
> >
> >   WARNING: "__moddi3" undefined!
> >
> > and, not surprisingly, when i try to insmod:
> >
> >   insmod: error inserting 'seq.ko': -1 Unknown symbol in module
> >
> > (using 16 rather than 15 works fine, as i assume that the modulus
> > call is simply replaced by an optimized  bitwise comparison.)
> >
> >   so ... from where comes __moddi3?  i know there are places in the
> > kernel source tree that do non-power-of-2 moduli, and they work fine,
> > no?  thanks.
>
> let me guess, 32 bit kernel, and var is 64 bit?

um ... yeah.  duh.  var type is actually loff_t.  i should have
realized that.

> gcc translates that into a libgcc call, which we _explicitly_ do not
> have because 64bit divisions are expensive!
>
> use do_div().

gotcha.  thanks.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: from where comes "__moddi3"?

[Jan Engelhardt]

On Jul 21 2007 23:33, Alexander Shishkin wrote:
> On 7/21/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
>>
>>   again, probably displaying my abject ignorance, but i wrote a
>> trivial module that tries to "var % 15", and i get:
>>
>>   WARNING: "__moddi3" undefined!
> ...which comes from libgcc1 which you obviously don't want to link against.
>
> Does (var & 0x0f) not work for you?

v & 0x0F  <=>  v % 16



	Jan
-- 

Re: from where comes "__moddi3"?

[Jan-Benedict Glaw]

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

On Sat, 2007-07-21 21:31:13 +0200, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
> 
> use do_div().
> 
> 16 works because gcc translates that into a right shift.

Right shift?  Doesn't it just mask out everything but the low 4 bit?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:             God put me on earth to accomplish a certain number of
the second  :            things. Right now I am so far behind I will never die.

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

Re: from where comes "__moddi3"?

[Alexander Shishkin]

On 7/21/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
> v & 0x0F  <=>  v % 16
Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.

Regards,
-- 
Alex

Re: from where comes "__moddi3"?

[Peter Zijlstra]

On Sat, 2007-07-21 at 21:58 +0200, Jan-Benedict Glaw wrote:
> On Sat, 2007-07-21 21:31:13 +0200, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
> > 
> > use do_div().
> > 
> > 16 works because gcc translates that into a right shift.
> 
> Right shift?  Doesn't it just mask out everything but the low 4 bit?

Yeah, its bitwise and for modulo and shifts for mult and div.

Silly mistake on my side.

RE: from where comes "__moddi3"?

[David Schwartz]

> On 7/21/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
> > v & 0x0F  <=>  v % 16
> Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.

Actually, it's the compiler's bad. That's a pretty fundamental equivalence that the compiler should recognize for native integral types.

DS

RE: from where comes "__moddi3"?

[Arjan van de Ven]

On Sat, 2007-07-21 at 14:27 -0700, David Schwartz wrote:
> > On 7/21/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
> > > v & 0x0F  <=>  v % 16
> > Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
> 
> Actually, it's the compiler's bad. That's a pretty fundamental equivalence that the compiler should recognize for native integral types.

for unsigned ones for sure yes... but the original question was about 15
not 16.