[llvmlinux] [PATCH] Make alignment cflags configurable.

Jan-Simon Moeller dl9pf at gmx.de
Wed Aug 12 23:17:53 UTC 2015


Am Mittwoch, 12. August 2015, 15:37:05 schrieb H. Peter Anvin:
> NAK.  This is crazy.

Ok roger that. What about the cc-option at least?

This way we can figure why it does not work for clang and keep things as-is 
for gcc.

JS

 
> On August 12, 2015 3:30:19 PM PDT, Jan-Simon Moeller <dl9pf at gmx.de> wrote:
> >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.htm
> >l
> >
> >
> ><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



More information about the LLVMLinux mailing list