All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: Masahiro Yamada <yamada.m@jp.panasonic.com>,
	Jeroen Hofstee <jeroen@myspectrum.nl>
Cc: u-boot@lists.denx.de, linux-kernel@vger.kernel.org
Subject: Re: [U-Boot] [RFC] kbuild.h: workaround for llvm IAS
Date: Sat, 28 Jun 2014 14:53:03 +0200	[thread overview]
Message-ID: <53AEBAAF.6020400@myspectrum.nl> (raw)
In-Reply-To: <20140627153815.7B85.AA925319@jp.panasonic.com>

Hello Masahiro,

On 27-06-14 08:38, Masahiro Yamada wrote:
> KBuild (ab)uses the asm statement to write to a file and
> llvm integrated as chokes about these invalid asm statements.
> Workaround it by making it look like valid asm code.
>
> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
>>> I think Linux has the same problem.
>>>
>>> Are you willing to this patch to linux-kbuild ML?
>>> Or fixing U-Boot only?
>> I don't mind in general, but it is just noise for them (cc-ing them to
>> create some).  For u-boot (ARM) you actually get a valid binary with
>> this patch after clang support has landed, for linux you just get other
>> errors as far as I tried (native only), patch below.
>>
>> However in linux there seem more spots relying on the format, e.g.
>>       arch/ia64/kvm/Makefile
>>       arch/ia64/kernel/Makefile
>>       arch/um/Makefile
>>
>> So if anything, I think this should be made a general rules first
>> in the makefiles. It seems stupid to potentially break something
>> while it gains nothing.
>>
>> So yes, u-boot only afaic, or does that make your syncing more difficult?
> I don't think syncing would be difficult.
>
> BTW, do you know how they resolve this build error in other projects,
> for example, in llvmlinux ?
> http://llvm.linuxfoundation.org/index.php/Main_Page
>
> Linux folks merged Clang support into the top Makefile, but not into ./Kbuild.
> I don't know why.
I don't know how the llvmlinux people do it, but the alternative is to
add -no-integrated-as for clang when compiling such files (or use an
older clang version, since that used to be the default). Since gcc's LTO
dislikes the asm-offset.c technique as well, I think it is better to 
actually
create valid asm, so it no longer depends on compiler features at all.
I will leave it up to the llvmlinux folks to come up with a solution for
linux though...

Regards,
Jeroen






WARNING: multiple messages have this Message-ID (diff)
From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] kbuild.h: workaround for llvm IAS
Date: Sat, 28 Jun 2014 14:53:03 +0200	[thread overview]
Message-ID: <53AEBAAF.6020400@myspectrum.nl> (raw)
In-Reply-To: <20140627153815.7B85.AA925319@jp.panasonic.com>

Hello Masahiro,

On 27-06-14 08:38, Masahiro Yamada wrote:
> KBuild (ab)uses the asm statement to write to a file and
> llvm integrated as chokes about these invalid asm statements.
> Workaround it by making it look like valid asm code.
>
> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
>>> I think Linux has the same problem.
>>>
>>> Are you willing to this patch to linux-kbuild ML?
>>> Or fixing U-Boot only?
>> I don't mind in general, but it is just noise for them (cc-ing them to
>> create some).  For u-boot (ARM) you actually get a valid binary with
>> this patch after clang support has landed, for linux you just get other
>> errors as far as I tried (native only), patch below.
>>
>> However in linux there seem more spots relying on the format, e.g.
>>       arch/ia64/kvm/Makefile
>>       arch/ia64/kernel/Makefile
>>       arch/um/Makefile
>>
>> So if anything, I think this should be made a general rules first
>> in the makefiles. It seems stupid to potentially break something
>> while it gains nothing.
>>
>> So yes, u-boot only afaic, or does that make your syncing more difficult?
> I don't think syncing would be difficult.
>
> BTW, do you know how they resolve this build error in other projects,
> for example, in llvmlinux ?
> http://llvm.linuxfoundation.org/index.php/Main_Page
>
> Linux folks merged Clang support into the top Makefile, but not into ./Kbuild.
> I don't know why.
I don't know how the llvmlinux people do it, but the alternative is to
add -no-integrated-as for clang when compiling such files (or use an
older clang version, since that used to be the default). Since gcc's LTO
dislikes the asm-offset.c technique as well, I think it is better to 
actually
create valid asm, so it no longer depends on compiler features at all.
I will leave it up to the llvmlinux folks to come up with a solution for
linux though...

Regards,
Jeroen

  reply	other threads:[~2014-06-28 12:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 21:40 [U-Boot] [RFC] kbuild.h: workaround for llvm IAS Jeroen Hofstee
2014-06-24 12:53 ` Masahiro Yamada
2014-06-24 19:36   ` Jeroen Hofstee
2014-06-24 19:36     ` Jeroen Hofstee
2014-06-27  6:38     ` Masahiro Yamada
2014-06-27  6:38       ` Masahiro Yamada
2014-06-28 12:53       ` Jeroen Hofstee [this message]
2014-06-28 12:53         ` Jeroen Hofstee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53AEBAAF.6020400@myspectrum.nl \
    --to=jeroen@myspectrum.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=u-boot@lists.denx.de \
    --cc=yamada.m@jp.panasonic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.