Messages in this thread | | | Date | Mon, 20 Jul 2009 18:01:42 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Linux 2.6.27.27 |
| |
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 /usr/lib/gcc/x86_64-redhat-linux/4.4.0/include -Iinclude -I/home/torvalds/v2.6/linux/arch/x86/include -include include/linux/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -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 -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fwrapv -fno-dwarf2-cfi-asm -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fork)" -D"KBUILD_MODNAME=KBUILD_STR(fork)" -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 binutils.
Crazy, crazy.
Linus
| |