9:10 a.m.
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
--
View this message in context:
http://www.nabble.com/gcc-4.3.0-0.4-and-building-kernel-src.rpm-tp1463404...
Sent from the Fedora Test List mailing list archive at Nabble.com.
7:36 p.m.
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.
--
Cheers
John
-- spambait
1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)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:-)
9:36 p.m.
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
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.
--
Cheers
John
-- spambait
1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)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(a)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
--
View this message in context:
http://www.nabble.com/gcc-4.3.0-0.4-and-building-kernel-src.rpm-tp1463404...
Sent from the Fedora Test List mailing list archive at Nabble.com.
10:05 p.m.
gjohnson5 wrote:
...
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
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.
10:33 p.m.
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
12:45 a.m.
gjohnson5 wrote:
>
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
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.
--
Cheers
John
-- spambait
1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)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:-)
7:10 a.m.
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
6:43 p.m.
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?
--
Cheers
John
-- spambait
1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)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:-)
2:33 a.m.
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
6:30 a.m.
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?
--
Cheers
John
-- spambait
1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)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:-)
6:35 a.m.
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
7:32 a.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHginp6YSQoMYUY94RAj5UAJ9oC2E+8NGkFvmBTs/rseftHPdPOwCff0/J
0gWZT7bvQiQTL5lnlSP6lBY=
=tJBl
-----END PGP SIGNATURE-----
5953
days inactive
5955
days old
11 comments
6 participants
participants (6)
-
Bryn M. Reeves -
Development discussions related to Fedora -
gjohnson5 -
Jakub Jelinek -
John Summerfield -
Kevin Kofler