|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Marc Dionne <marc.c.dionne-AT-gmail.com> |
|| ||Re: Linux 184.108.40.206 |
|| ||Mon, 20 Jul 2009 18:01:42 -0700 (PDT)|
|| ||Krzysztof Oledzki <olel-AT-ans.pl>, Greg KH <gregkh-AT-suse.de>,
Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>,
Andrew Morton <akpm-AT-linux-foundation.org>, stable-AT-kernel.org,
|| ||Article, Thread
On Mon, 20 Jul 2009, Marc Dionne wrote:
> > Hmm. This sounds more like the binutils bug that people had. Sounds like
> > an assembler bug if the *.o file ends up being empty or at some fixed
> > size. If it was cc1 that fails, I'd expect to not see an *.o file at all,
> > since it didn't generate good assembly.
> > In fact, your behavior sounds like the thing that produces the *.o files
> > core-dumped or died for other reasons, and had a 64kB buffer that either
> > got flushed or not. That would explain the "zero or exactly 64kB" size.
> > It could be ccache too, of course.
> Actually in my case it turns out that it is ccache after all - if I remove it
> from the picture everything is fine. If I re-enable it, even with a clean
> cache, I get the problem.
> It might just be a coincidence that it's triggered by the -fwrapv change.
Ok, so this is getting ridiculous. Do we have _three_ different kernel
issues going on at the same time, all subtly related to tools issues
rather than the kernel source tree itself?
That's just completely bizarre.
So right now we have:
- Krzysztof Oledzki: the only one who so far has really pinpointed it to
the -fwrapv change itself.
It would be good to really double-check that this is not about ccache,
since Marc apparently gets a good kernel without ccache, and -fwrapv
seems to be involved.
- Marc Dionne: ccache getting confused, with 0-byte and 64kB object
files. But why -fwrapv vs -fno-strict-overflow would matter is totally
unclear. Just happenstance? Something silly like overflowing the
length of the ccache argument buffer?
It would be wonderful to figure out what odd issue ccache might have.
The kernel command line isn't _that_ long, but it does end up being
something reasonably monstrous like
gcc -Wp,-MD,kernel/.fork.s.d -nostdinc -isystem
include/linux/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common
-fno-delete-null-pointer-checks -Os -m64 -march=core2 -mno-red-zone
-mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-Wframe-larger-than=2048 -fno-stack-protector -fno-omit-frame-pointer
-Wno-pointer-sign -fwrapv -fno-dwarf2-cfi-asm -D"KBUILD_STR(s)=#s"
-fverbose-asm -S -o kernel/fork.s kernel/fork.c
so we are getting into the kilobyte range for it, and mayeb simply the
longer argument made something fail. But other build systems do even
worse things, I'm sure.
- the Debian/sid binutils package failure, solved by downgrading
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)