Hi all! > You could mention that this is to fix the clang build. But why is it > needed? It isn't that clang just doesn't accept the option, is it? > Otherwise we could just use $(call cc-option, -falign-jumps=1) etc.
Yes it is to fix the build with clang. I tried cc-option, but it does not improve the situation (more below). This is why I chose the config option approach in the patch. > Did you get to the bottom of the clang failure here? Just turning this > off without a coherent explanation doesn't seem like the right thing to > do. I know it is not the final solution which is why I turned it into a config option. We can still debate if default should be "y" or "n". This way we all can proceed. @Ingo: would it be fine if we wrap it into a config option defaulting to "y" ? What I can say so far is that although clang warns about the unknown option and ignores it, the resulting kernel still fails to boot somewhere early in start_kernel(). I'm still investigating. My current trace ends like this: page_address_init ~ setup_arch ~ then arch/x86/kernel/setup.c:898 setup.c:898 is a printk actually ... early_idt_handler_array[i] ~> early_idt_handler_common The mail thread is here: http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-August/001276.html <wild guess> We still build with -no-integrated-as which means we use gas. Maybe the flag is passed-on there and things get confused. </wile guess> Best, Jan-Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
