Why are we building kernels with this broken compiler? http://bugzilla.kernel.org/show_bug.cgi?id=8501 http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log
> Why are we building kernels with this broken compiler? > > http://bugzilla.kernel.org/show_bug.cgi?id=8501 > > http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.logWhy are we building these broken kernels with our shiny new compiler?
On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote:> > Why are we building kernels with this broken compiler? > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8501 > > > > http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log > > Why are we building these broken kernels with our shiny new compiler? >Does using -ffreestanding fix these references to libgcc? I notice we''re not using it when we build x86 or powerpc kernels, where we see this... cheers, Kyle
On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote:> On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote: > > > Why are we building kernels with this broken compiler? > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8501 > > > > > > http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log > > > > Why are we building these broken kernels with our shiny new compiler? > > > > Does using -ffreestanding fix these references to libgcc? I notice > we''re not using it when we build x86 or powerpc kernels, where we see > this...No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1] self-contained and assumed to be present in both -fhosted and -ffreestanding linking. This is nothing new, has been like that for many years. AFAIK kernel on several architectures uses libgcc.a, on those where it intentionally decides not to do that, it either needs to supply its own implementation of the needed entrypoints, or make sure they are not needed. In this case you should put in an asm optimization barrier into the loop to avoid optimizing the loop into modulo. See the gcc PR opened for it. [1] exceptions are that __eprintf assumes stdio, -ftrapv helpers assume abort, the rest is really self-contained, and kernel really has no reason to use either __eprintf, nor is compiled with -ftrapv Jakub
On 02/01/2008 03:46 AM, Jakub Jelinek wrote:> On Thu, Jan 31, 2008 at 07:50:42PM -0500, Kyle McMartin wrote: >> On Thu, Jan 31, 2008 at 04:47:55PM -0800, Roland McGrath wrote: >>>> Why are we building kernels with this broken compiler? >>>> >>>> http://bugzilla.kernel.org/show_bug.cgi?id=8501 >>>> >>>> http://koji.fedoraproject.org/koji/getfile?taskID=388196&name=build.log >>> Why are we building these broken kernels with our shiny new compiler? >>> >> Does using -ffreestanding fix these references to libgcc? I notice >> we''re not using it when we build x86 or powerpc kernels, where we see >> this... > > No, even -ffreestanding assumes libgcc is used. libgcc.a is mostly[1] > self-contained and assumed to be present in both -fhosted and -ffreestanding > linking. This is nothing new, has been like that for many years. > AFAIK kernel on several architectures uses libgcc.a, on those where it > intentionally decides not to do that, it either needs to supply its own > implementation of the needed entrypoints, or make sure they are not needed. > In this case you should put in an asm optimization barrier into the loop > to avoid optimizing the loop into modulo. See the gcc PR opened for it. >The below patch fixes it too, but that just leads to the next error (on ppc64): drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a section type conflict Was someone supposed to test building the kernel package with the new compiler before making it the default? --- linux-2.6.24.noarch.orig/include/linux/time.h +++ linux-2.6.24.noarch/include/linux/time.h @@ -169,7 +169,7 @@ extern struct timeval ns_to_timeval(cons * @a: pointer to timespec to be incremented * @ns: unsigned nanoseconds value to be added */ -static inline void timespec_add_ns(struct timespec *a, u64 ns) +static inline void timespec_add_ns(struct timespec *a, volatile u64 ns) { ns += a->tv_nsec; while(unlikely(ns >= NSEC_PER_SEC)) {
On 02/01/2008 05:17 PM, Jan Kratochvil wrote:> On Fri, 01 Feb 2008 22:06:29 +0100, Chuck Ebbert wrote: > ... >> And, after fixing that one we get (on ppc): >> >> *** ERROR: same build ID in nonidentical files! >> /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux >> and /boot/vmlinuz-2.6.24-14.fc9 > > Currently: > > vmlinuz-$VER: Not marked as executable and therefore not splitted into > binary + .debug > vmlinux: Copied directly into /usr/lib/debug and therefore its stripped part is > duplicite to the vmlinuz-$VER one > > Proposing: > > vmlinuz-$VER: Marked as executable, split into a separete vmlinuz-$VER.debug > vmlinux: Just a symlink into vmlinuz-$VER, GDB will load the vmlinuz-$VER.debug > file for it. This symlink could be dropped but some tools may expect > the /lib/modules/$VER/vmlinux file to exist. Still they will now have > to deal with the split binary + .debug file for it. > > If you agree I can test if it works well, it takes a lot of time to build it. > > > > Regards, > Jan > > > ------------------------------------------------------------------------ > > --- kernel.spec 1 Feb 2008 17:45:46 -0000 1.398 > +++ kernel.spec 1 Feb 2008 22:10:44 -0000 > @@ -1422,8 +1422,14 @@ BuildKernel() { > # save the vmlinux file for kernel debugging into the kernel-debuginfo rpm > # > %if %{with_debuginfo} > - mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > - cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > + if [ $KernelImage != vmlinux ]; then > + mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > + cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer > + else > + # mark it executable so that strip-to-file can strip it > + chmod u+x $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer > + ln -s %{image_install_path}/vmlinuz-$KernelVer $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux > + fi > %endif > > find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnamesRoland is looking into this; I added a cc: for him.