I am using gcc-4.3.0-0.4 with glibc-2.7.90-3 (not sure if that matters) with rawhide and I am getting this building kernel-2.6.23.12-101.fc8
drivers/video/cfbimgblt.c:129:12: warning: cast adds address space to expression (asn:2) CHK include/linux/compile.h UPD include/linux/compile.h init/version.c:19:5: warning: symbol 'Version_132631' was not declared. Should it be static? kernel/built-in.o: In function `getnstimeofday': (.text+0x1d525): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d5ef): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d612): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x1d7dd): undefined reference to `__udivdi3' timekeeping.c:(.text+0x1d800): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1de63): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1de86): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1df24): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1df4e): undefined reference to `__umoddi3' make: *** [.tmp_vmlinux1] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.80567 (%build)
I was under the impression that those math functions were provided by libgcc so I was assuming it was the compiler with the issue. So , I'm just wondering what is broken
gjohnson5 wrote:
I am using gcc-4.3.0-0.4 with glibc-2.7.90-3 (not sure if that matters) with rawhide and I am getting this building kernel-2.6.23.12-101.fc8
drivers/video/cfbimgblt.c:129:12: warning: cast adds address space to expression (asn:2) CHK include/linux/compile.h UPD include/linux/compile.h init/version.c:19:5: warning: symbol 'Version_132631' was not declared. Should it be static? kernel/built-in.o: In function `getnstimeofday': (.text+0x1d525): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d5ef): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d612): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x1d7dd): undefined reference to `__udivdi3' timekeeping.c:(.text+0x1d800): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1de63): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1de86): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1df24): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1df4e): undefined reference to `__umoddi3' make: *** [.tmp_vmlinux1] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.80567 (%build)
I was under the impression that those math functions were provided by libgcc so I was assuming it was the compiler with the issue. So , I'm just wondering what is broken
1. the kernel does not use any libraries external to itself; those external libraries include userland->kernel interfaces, and those are not what the kernel requires. 2. Did you read your kernel's documentation to see what tools you might use? Using an unsupported compiler is problematic.
John Summerfield wrote:
gjohnson5 wrote:
I am using gcc-4.3.0-0.4 with glibc-2.7.90-3 (not sure if that matters) with rawhide and I am getting this building kernel-2.6.23.12-101.fc8
drivers/video/cfbimgblt.c:129:12: warning: cast adds address space to expression (asn:2) CHK include/linux/compile.h UPD include/linux/compile.h init/version.c:19:5: warning: symbol 'Version_132631' was not declared. Should it be static? kernel/built-in.o: In function `getnstimeofday': (.text+0x1d525): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d5ef): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d612): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x1d7dd): undefined reference to `__udivdi3' timekeeping.c:(.text+0x1d800): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1de63): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1de86): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1df24): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x1df4e): undefined reference to `__umoddi3' make: *** [.tmp_vmlinux1] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.80567 (%build)
I was under the impression that those math functions were provided by libgcc so I was assuming it was the compiler with the issue. So , I'm just wondering what is broken
- the kernel does not use any libraries external to itself; those
external libraries include userland->kernel interfaces, and those are not what the kernel requires. 2. Did you read your kernel's documentation to see what tools you might use? Using an unsupported compiler is problematic.
--
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
1. ok didnt know for sure 2. gcc , and the kernel come from koji... only reason I tried it was testing , I don't necessarily need to use if you are implying that I should not use the latest gcc from koji to compile Fedora kernel src.rpm What documentation is available for compiling kernels for Rawhide? I will definitely read it
gjohnson5 wrote: ...
- gcc , and the kernel come from koji... only reason I tried it was
testing , I don't necessarily need to use if you are implying that I should not use the latest gcc from koji to compile Fedora kernel src.rpm
I seem to remember that the fedora builders used earlier known to be stable gcc's to build fedora packages. Using the latest gcc will ensure you get to trip on the issues ;) and need to keep bugzilla.redhat.com handy ?
What documentation is available for compiling kernels for Rawhide? I will definitely read it
try: http://fedoraproject.org/wiki/Docs/CustomKernel
It might be useful to build a rawhide kernel with the F8 tools/compilers, to prove you have the build process down pat before stepping into the less charted territory.
DaveT.
David Timms <dtimms <at> iinet.net.au> writes:
I seem to remember that the fedora builders used earlier known to be stable gcc's to build fedora packages. Using the latest gcc will ensure you get to trip on the issues ;) and need to keep bugzilla.redhat.com handy ?
Koji (the Fedora build system) normally uses the current GCC in the buildroot, which is essentially the latest GCC in Rawhide (give or take a few hours), to build Rawhide builds. However, in this case, GCC 4.3 is currently being introduced in a separate buildroot, it's not in Rawhide yet. When it'll hit Rawhide, the Rawhide kernels will of course have to be fixed to work with it. (However, the Fedora 8 kernel the original poster apparently tried to build with GCC 4.3 probably won't (until/unless upstream fixes it and F8 rebases to the new upstream kernel)!)
Kevin Kofler
gjohnson5 wrote:
- ok didnt know for sure
- gcc , and the kernel come from koji... only reason I tried it was
testing , I don't necessarily need to use if you are implying that I should not use the latest gcc from koji to compile Fedora kernel src.rpm What documentation is available for compiling kernels for Rawhide? I will definitely read it
I'm not saying anything about which compiler you should use, I don't know. I do know that in the past is has mattered.
The documentation you need to read is in the kernel source. It gives a full list of the software you need, how to test whether you have the right version.
On Sat, Jan 05, 2008 at 07:10:29AM -0800, gjohnson5 wrote:
I am using gcc-4.3.0-0.4 with glibc-2.7.90-3 (not sure if that matters) with rawhide and I am getting this building kernel-2.6.23.12-101.fc8
drivers/video/cfbimgblt.c:129:12: warning: cast adds address space to expression (asn:2) CHK include/linux/compile.h UPD include/linux/compile.h init/version.c:19:5: warning: symbol 'Version_132631' was not declared. Should it be static? kernel/built-in.o: In function `getnstimeofday': (.text+0x1d525): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d5ef): undefined reference to `__udivdi3'
...
See http://gcc.gnu.org/PR32044 __udivdi3/__umoddi3 are in libgcc.a and gcc relies on it libgcc being available, but the kernel chooses to link without libgcc - for some routines it has its own counterparts, for some it chooses not to implement them at all and just assumes they won't be needed.
The optimization in question without __builtin_expect is a clear win, at least unless there are really very few iterations or the target has an instruction to do the division or modulo. With __builtin_expect saying that looping is unexpected this is more questionable, see the PR above for more details. That said, when kernel intentionally avoids libgcc, IMHO it must be prepare to tweak its sources to ensure it is not needed. I think best is to insert an optimization barrier in the 2 or how many loops are there in the kernel where this optimization turns a loop into > wordsize division/modulo.
Jakub
Jakub Jelinek wrote:
On Sat, Jan 05, 2008 at 07:10:29AM -0800, gjohnson5 wrote:
I am using gcc-4.3.0-0.4 with glibc-2.7.90-3 (not sure if that matters) with rawhide and I am getting this building kernel-2.6.23.12-101.fc8
drivers/video/cfbimgblt.c:129:12: warning: cast adds address space to expression (asn:2) CHK include/linux/compile.h UPD include/linux/compile.h init/version.c:19:5: warning: symbol 'Version_132631' was not declared. Should it be static? kernel/built-in.o: In function `getnstimeofday': (.text+0x1d525): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1d5ef): undefined reference to `__udivdi3'
...
See http://gcc.gnu.org/PR32044 __udivdi3/__umoddi3 are in libgcc.a and gcc relies on it libgcc being available, but the kernel chooses to link without libgcc - for some routines it has its own counterparts, for some it chooses not to implement them at all and just assumes they won't be needed.
It doesn't "assume they won't be needed," the kernel is written to be self-complete.
Think a while, what place does user-space code have in the kernel?
On Mon, Jan 07, 2008 at 09:43:24AM +0900, John Summerfield wrote:
See http://gcc.gnu.org/PR32044 __udivdi3/__umoddi3 are in libgcc.a and gcc relies on it libgcc being available, but the kernel chooses to link without libgcc - for some routines it has its own counterparts, for some it chooses not to implement them at all and just assumes they won't be needed.
It doesn't "assume they won't be needed," the kernel is written to be self-complete.
Think a while, what place does user-space code have in the kernel?
libgcc routines are self-complete. And on a bunch of architectures Linux kernel is linked with libgcc.a, e.g. sh{,64}, xtensa, pa, cris, h8300, m32r. If you do nm on i386 libgcc.a, you'll see: ... _divdi3.o: 0000000000000000 T __divdi3
_moddi3.o: 0000000000000000 T __moddi3
_udivdi3.o: 0000000000000000 T __udivdi3
_umoddi3.o: 0000000000000000 T __umoddi3
... i.e. all these routines don't need anything else.
Jakub
Jakub Jelinek wrote:
On Mon, Jan 07, 2008 at 09:43:24AM +0900, John Summerfield wrote:
See http://gcc.gnu.org/PR32044 __udivdi3/__umoddi3 are in libgcc.a and gcc relies on it libgcc being available, but the kernel chooses to link without libgcc - for some routines it has its own counterparts, for some it chooses not to implement them at all and just assumes they won't be needed.
It doesn't "assume they won't be needed," the kernel is written to be self-complete.
Think a while, what place does user-space code have in the kernel?
libgcc routines are self-complete. And on a bunch of architectures Linux kernel is linked with libgcc.a, e.g. sh{,64}, xtensa, pa, cris,
I know arguing with a Red Hatter was risky:-)
h8300, m32r. If you do nm on i386 libgcc.a, you'll see: ... _divdi3.o: 0000000000000000 T __divdi3
_moddi3.o: 0000000000000000 T __moddi3
_udivdi3.o: 0000000000000000 T __udivdi3
_umoddi3.o: 0000000000000000 T __umoddi3
... i.e. all these routines don't need anything else.
Jakub
My only F8 system is entirely 64-bit Intel. If used, should those appear in System.map? I couldn't see any.
Or is this a new innovation?
On Mon, Jan 07, 2008 at 09:30:25PM +0900, John Summerfield wrote:
My only F8 system is entirely 64-bit Intel. If used, should those appear in System.map? I couldn't see any.
x86_64 has 64-bit division and modulo insns in hw, so for 64-bit arithmetics x86_64 code doesn't use libgcc helpers. For 128-bit arithmetics it does though...
Jakub
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Summerfield wrote:
It doesn't "assume they won't be needed," the kernel is written to be self-complete.
Think a while, what place does user-space code have in the kernel?
This isn't "user-space code", it's math operations for > word sized operands that appear in the object code as a result of optimisations GCC is carrying out.
Regards,
Bryn.