From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 02/34] xen: clang: Disable built-in assembler Date: Wed, 26 Mar 2014 15:30:52 +0000 Message-ID: <533300BC02000078000027D4@nat28.tlf.novell.com> References: <1395766541-23979-1-git-send-email-julien.grall@linaro.org> <1395766541-23979-3-git-send-email-julien.grall@linaro.org> <5332CDE00200007800002490@nat28.tlf.novell.com> <20140326131625.GB7885@deinos.phlegethon.org> <5332ED80.5070305@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WSpn6-0000V9-3g for xen-devel@lists.xenproject.org; Wed, 26 Mar 2014 15:30:56 +0000 In-Reply-To: <5332ED80.5070305@linaro.org> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , Tim Deegan Cc: xen-devel@lists.xenproject.org, Keir Fraser , stefano.stabellini@citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org >>> On 26.03.14 at 16:08, wrote: > Hi Tim, > > On 03/26/2014 01:16 PM, Tim Deegan wrote: >> At 11:53 +0000 on 26 Mar (1395831232), Jan Beulich wrote: >>>>>> On 25.03.14 at 17:55, wrote: >>>> --- a/xen/Rules.mk >>>> +++ b/xen/Rules.mk >>>> @@ -74,6 +74,7 @@ AFLAGS-y += -D__ASSEMBLY__ -include >>>> $(BASEDIR)/include/xen/config >>>> >>>> # Clang's built-in assembler can't handle .code16/.code32/.code64 yet >>>> AFLAGS-$(clang) += -no-integrated-as >>>> +CFLAGS-$(clang) += -no-integrated-as >>> >>> Iirc Tim had found and worked around other built-in assembler issues >>> in the past, so if this is to be done unconditionally I wonder whether >>> we shouldn't then drop those workarounds. >> >> I would prefer, wherever possible, to make things work with the clang >> assembler rather than rely on the binutils one forever. > > The clang integrated assembler is too powerful for some part of Xen :). > Every inline assembly code is parsing by the assembler to check the syntax. > > This will result to failure to generate asm-offsets.c because of the -> > in the code (see arch/arm/arm32/asm-offsets.c: DEFINE/BLANK macros). > Indeed, the -> is not a valid assembler syntax. But what business does the compiler have to pass the assembly code to its internal assembler when all it was asked was to output assembly? That may be acceptable as an optional internal consistency check (verifying the compiler produced valid assembly), but shouldn't constrain the user from using the compiler for things where it's known the output isn't going to be valid assembly. That said, I think it wouldn't be too difficult to change the asm-offsets logic to produce something that does look like valid assembly. Jan