[2.6.37-rc1] Build failure: __divdi3

[2.6.37-rc1] Build failure: __divdi3

[Tetsuo Handa]

WARNING: modpost: Found 5 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
fs/built-in.o(.text+0x3e357): In function `alignfile':
: undefined reference to `__divdi3'
fs/built-in.o(.text+0x3e39b): In function `alignfile':
: undefined reference to `__divdi3'
fs/built-in.o(.text+0x3f1af): In function `elf_core_dump':
: undefined reference to `__divdi3'
make: *** [.tmp_vmlinux1] Error 1

Regards.

Re: [2.6.37-rc1] Build failure: __divdi3

[Randy Dunlap]

On Fri, 05 Nov 2010 17:59:42 +0900 Tetsuo Handa wrote:

> 
> WARNING: modpost: Found 5 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> fs/built-in.o(.text+0x3e357): In function `alignfile':
> : undefined reference to `__divdi3'
> fs/built-in.o(.text+0x3e39b): In function `alignfile':
> : undefined reference to `__divdi3'
> fs/built-in.o(.text+0x3f1af): In function `elf_core_dump':
> : undefined reference to `__divdi3'
> make: *** [.tmp_vmlinux1] Error 1


Hm, all due to usage of roundup() AFAICT.  Unfortunate.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [2.6.37-rc1] Build failure: __divdi3

[Tetsuo Handa]

Hello.

Randy Dunlap wrote:
> On Fri, 05 Nov 2010 17:59:42 +0900 Tetsuo Handa wrote:
> 
> > 
> > WARNING: modpost: Found 5 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > fs/built-in.o(.text+0x3e357): In function `alignfile':
> > : undefined reference to `__divdi3'
> > fs/built-in.o(.text+0x3e39b): In function `alignfile':
> > : undefined reference to `__divdi3'
> > fs/built-in.o(.text+0x3f1af): In function `elf_core_dump':
> > : undefined reference to `__divdi3'
> > make: *** [.tmp_vmlinux1] Error 1
> 
> 
> Hm, all due to usage of roundup() AFAICT.  Unfortunate.

Indeed. There is a commit for avoiding 64-bit division.

  commit ea7f1b6ee9dc96c5827b06ba21d7769d553efb7d
  Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
  Date:   Thu Nov 5 11:17:11 2009 -0600
  
      x86/PCI: remove 64-bit division
  
      The roundup() caused a build error (undefined reference to `__udivdi3').
      We're aligning to power-of-two boundaries, so it's simpler to just use
      ALIGN() anyway, which avoids the division.
  
      Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

It seems that the code itself has not changed between 2.6.36 and 2.6.37-rc1

  static int elf_core_dump(struct coredump_params *cprm)
  {
  (...snipped...)
  	loff_t offset = 0, dataoff, foffset;
  (...snipped...)
  	dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);

but the definition of roundup() has changed by

  commit b28efd54d9d5c8005a29cd8782335beb9daaa32d
  Author: Eric Paris <eparis@redhat.com>
  Date:   Wed Oct 13 17:50:08 2010 -0400
  
      kernel: roundup should only reference arguments once
  
      Currently the roundup macro references it's arguments more than one time.
      This patch changes it so it will only use its arguments once.
  
      Suggested-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Eric Paris <eparis@redhat.com>
      Signed-off-by: James Morris <jmorris@namei.org>

between 2.6.36 and 2.6.37-rc1.

Re: [2.6.37-rc1] Build failure: __divdi3

[Eric Paris]

On Sat, 2010-11-06 at 01:48 +0900, Tetsuo Handa wrote:
> Hello.
> 
> Randy Dunlap wrote:
> > On Fri, 05 Nov 2010 17:59:42 +0900 Tetsuo Handa wrote:
> > 
> > > 
> > > WARNING: modpost: Found 5 section mismatch(es).
> > > To see full details build your kernel with:
> > > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > > fs/built-in.o(.text+0x3e357): In function `alignfile':
> > > : undefined reference to `__divdi3'
> > > fs/built-in.o(.text+0x3e39b): In function `alignfile':
> > > : undefined reference to `__divdi3'
> > > fs/built-in.o(.text+0x3f1af): In function `elf_core_dump':
> > > : undefined reference to `__divdi3'
> > > make: *** [.tmp_vmlinux1] Error 1
> > 
> > 
> > Hm, all due to usage of roundup() AFAICT.  Unfortunate.
> 
> Indeed. There is a commit for avoiding 64-bit division.
> 
>   commit ea7f1b6ee9dc96c5827b06ba21d7769d553efb7d
>   Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
>   Date:   Thu Nov 5 11:17:11 2009 -0600
>   
>       x86/PCI: remove 64-bit division
>   
>       The roundup() caused a build error (undefined reference to `__udivdi3').
>       We're aligning to power-of-two boundaries, so it's simpler to just use
>       ALIGN() anyway, which avoids the division.
>   
>       Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>       Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
>       Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> It seems that the code itself has not changed between 2.6.36 and 2.6.37-rc1
> 
>   static int elf_core_dump(struct coredump_params *cprm)
>   {
>   (...snipped...)
>   	loff_t offset = 0, dataoff, foffset;
>   (...snipped...)
>   	dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
> 
> but the definition of roundup() has changed by
> 
>   commit b28efd54d9d5c8005a29cd8782335beb9daaa32d
>   Author: Eric Paris <eparis@redhat.com>
>   Date:   Wed Oct 13 17:50:08 2010 -0400
>   
>       kernel: roundup should only reference arguments once
>   
>       Currently the roundup macro references it's arguments more than one time.
>       This patch changes it so it will only use its arguments once.
>   
>       Suggested-by: Andrew Morton <akpm@linux-foundation.org>
>       Signed-off-by: Eric Paris <eparis@redhat.com>
>       Signed-off-by: James Morris <jmorris@namei.org>
> 
> between 2.6.36 and 2.6.37-rc1.

Interesting, is this a result of the compiler previously being able to
optimize the division since it could tell it was a power of 2 and now
that we have a private variable it can't?  The patch can easily be
reverted without breaking anyone else....

-Eric

Re: [2.6.37-rc1] Build failure: __divdi3

[Tetsuo Handa]

Eric Paris wrote:
> Interesting, is this a result of the compiler previously being able to
> optimize the division since it could tell it was a power of 2 and now
> that we have a private variable it can't?  The patch can easily be
> reverted without breaking anyone else....

It seems that GCC 3.x can optimize

  roundup((long long), (const))

but cannot optimize

  #define roundup(x, y) (                                 \
  {                                                       \
  	typeof(y) __y = y;                              \
  	(((x) + (__y - 1)) / __y) * __y;                \
  }                                                       \
  )

when y is a constant value.

Re: [2.6.37-rc1] Build failure: __divdi3

[Tetsuo Handa]

Tetsuo Handa wrote:
> Eric Paris wrote:
> > Interesting, is this a result of the compiler previously being able to
> > optimize the division since it could tell it was a power of 2 and now
> > that we have a private variable it can't?  The patch can easily be
> > reverted without breaking anyone else....
> 
I meant to say that it seems that GCC 3.x can optimize

  #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))

for roundup((long long), (const)) case but cannot optimize

  #define roundup(x, y) (                                 \
  {                                                       \
  	typeof(y) __y = y;                              \
  	(((x) + (__y - 1)) / __y) * __y;                \
  }                                                       \
  )

for roundup((long long), (const)) case.

Re: [2.6.37-rc1] Build failure: __divdi3

[Eric Paris]

On Sat, 2010-11-06 at 02:16 +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Eric Paris wrote:
> > > Interesting, is this a result of the compiler previously being able to
> > > optimize the division since it could tell it was a power of 2 and now
> > > that we have a private variable it can't?  The patch can easily be
> > > reverted without breaking anyone else....
> > 
> I meant to say that it seems that GCC 3.x can optimize
> 
>   #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
> 
> for roundup((long long), (const)) case but cannot optimize
> 
>   #define roundup(x, y) (                                 \
>   {                                                       \
>   	typeof(y) __y = y;                              \
>   	(((x) + (__y - 1)) / __y) * __y;                \
>   }                                                       \
>   )
> 
> for roundup((long long), (const)) case.

I guess this is my fault (I'm not completely convinced) since my testing
was done with gcc 4.  I just retested to make sure that
gcc-4.5.1-4.fc14.x86_64 is able to optimize both (and it does).  Is the
fact that it requires compiler optimizations for the code to build a
good thing?

-Eric

Re: [2.6.37-rc1] Build failure: __divdi3

[Andrew Morton]

On Fri, 05 Nov 2010 13:41:45 -0400
Eric Paris <eparis@redhat.com> wrote:

> On Sat, 2010-11-06 at 02:16 +0900, Tetsuo Handa wrote:
> > Tetsuo Handa wrote:
> > > Eric Paris wrote:
> > > > Interesting, is this a result of the compiler previously being able to
> > > > optimize the division since it could tell it was a power of 2 and now
> > > > that we have a private variable it can't?  The patch can easily be
> > > > reverted without breaking anyone else....
> > > 
> > I meant to say that it seems that GCC 3.x can optimize
> > 
> >   #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
> > 
> > for roundup((long long), (const)) case but cannot optimize
> > 
> >   #define roundup(x, y) (                                 \
> >   {                                                       \
> >   	typeof(y) __y = y;                              \
> >   	(((x) + (__y - 1)) / __y) * __y;                \
> >   }                                                       \
> >   )
> > 
> > for roundup((long long), (const)) case.
> 
> I guess this is my fault (I'm not completely convinced) since my testing
> was done with gcc 4.  I just retested to make sure that
> gcc-4.5.1-4.fc14.x86_64 is able to optimize both (and it does).  Is the
> fact that it requires compiler optimizations for the code to build a
> good thing?

It does make us pretty fragile against future compiler versions, but we
do rely quite a lot on such compiler things.  And things do break, such
as the several-month outbreak of calls to
you_cannot_kmalloc_that_much() a while back.

I wonder if there's some way of tricking gcc back into doing the right
thing here.  Make __y const or something?

Re: [2.6.37-rc1] Build failure: __divdi3

[Tetsuo Handa]

Andrew Morton wrote:
> > >   #define roundup(x, y) (                                 \
> > >   {                                                       \
> > >   	typeof(y) __y = y;                              \
> > >   	(((x) + (__y - 1)) / __y) * __y;                \
> > >   }                                                       \
> > >   )
> > > 
> > > for roundup((long long), (const)) case.
> > 
> > I guess this is my fault (I'm not completely convinced) since my testing
> > was done with gcc 4.  I just retested to make sure that
> > gcc-4.5.1-4.fc14.x86_64 is able to optimize both (and it does).  Is the
> > fact that it requires compiler optimizations for the code to build a
> > good thing?
> 
> It does make us pretty fragile against future compiler versions, but we
> do rely quite a lot on such compiler things.  And things do break, such
> as the several-month outbreak of calls to
> you_cannot_kmalloc_that_much() a while back.
> 
> I wonder if there's some way of tricking gcc back into doing the right
> thing here.  Make __y const or something?

Nice suggestion.

-typeof(y) __y = y;
+const typeof(y) __y = y;

solved __divdi3 problem with GCC 3.3.5.

Regards.

Re: [2.6.37-rc1] Build failure: __divdi3

[Andrew Morton]

On Sat, 6 Nov 2010 03:36:27 +0900
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:

> Andrew Morton wrote:
> > > >   #define roundup(x, y) (                                 \
> > > >   {                                                       \
> > > >   	typeof(y) __y = y;                              \
> > > >   	(((x) + (__y - 1)) / __y) * __y;                \
> > > >   }                                                       \
> > > >   )
> > > > 
> > > > for roundup((long long), (const)) case.
> > > 
> > > I guess this is my fault (I'm not completely convinced) since my testing
> > > was done with gcc 4.  I just retested to make sure that
> > > gcc-4.5.1-4.fc14.x86_64 is able to optimize both (and it does).  Is the
> > > fact that it requires compiler optimizations for the code to build a
> > > good thing?
> > 
> > It does make us pretty fragile against future compiler versions, but we
> > do rely quite a lot on such compiler things.  And things do break, such
> > as the several-month outbreak of calls to
> > you_cannot_kmalloc_that_much() a while back.
> > 
> > I wonder if there's some way of tricking gcc back into doing the right
> > thing here.  Make __y const or something?
> 
> Nice suggestion.
> 
> -typeof(y) __y = y;
> +const typeof(y) __y = y;
> 
> solved __divdi3 problem with GCC 3.3.5.
> 

OK, thanks.  Pending any better ideas, I typed this in:


From: Andrew Morton <akpm@linux-foundation.org>

gcc-3.3.5 (at least) is failing to optimise away the divide when `y' is a
constant 64-bit power-of-two value - it emits a call to __divdi3().

It turns out that defining `y' as const prevents this.

Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Eric Paris <eparis@redhat.com>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/kernel.h |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff -puN include/linux/kernel.h~include-linux-kernelh-roundup-work-around-a-gcc-33-miscompile include/linux/kernel.h
--- a/include/linux/kernel.h~include-linux-kernelh-roundup-work-around-a-gcc-33-miscompile
+++ a/include/linux/kernel.h
@@ -58,9 +58,11 @@ extern const char linux_proc_banner[];
 
 #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+
+/* The `const' in roundup() prevents gcc-3.3 from calling __divdi3 */
 #define roundup(x, y) (					\
 {							\
-	typeof(y) __y = y;				\
+	const typeof(y) __y = y;			\
 	(((x) + (__y - 1)) / __y) * __y;		\
 }							\
 )
_